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INTRODUCTION 


This  final  report  summarizes  the  tasks  performed  by  Battelle  under  contract 
number  F33615-83-C-2382.  Through  the  use  of  this  contract  Battelle  provided 
facility  support  for  the  computer  systems  used  in  the  research  and  development 
(R&D)  facilities  of  the  Technology  Branch,  Turbine  Engine  Division,  Air  Force 
Wright  Aeronautical  Laboratories  (AFWAL)  at  Wright-Patterson  Air  Force  Base. 


SCOPE 

Battelle  provided  maintenance  and  enhancement  support  of  Technology  Branch  R&D 
facility  software  and  related  automated  data  processing  equipment  (ADPE) 
devices.  Areas  of  support  included  facility  and  test  article  control,  data 
acquisition,  facility  and  test  article  simulation,  operator  interface,  data 
processing,  documentation,  and  operating  system  upgrades.  The  effort  involved 
work  performed  "off  site"  at  Battelle's  Columbus  Laboratory  and  "on  site"  at 
the  Aero  Propulsion  Laboratory's  Compressor  Research  Facility  (CRF). 


BACKGROUND 

The  mission  of  the  Technology  Branch  is  to  conduct  research  and  development  on 
gas  turbine  engine  compressors.  The  actual  testing  of  compressors  is 
performed  in  the  Branch's  Compressor  Research  Facility  (CRF).  The  test 
article  is  driven  by  one  of  two  30,000  hp  synchronous  electric  motors,  coupled 
by  a  gearbox  system  that  can  increase  test  article  speed  up  to  30,000  rpm. 

The  drive  motor  power  conditioning  is  accomplished  by  a  complex  arrangement  of 
motors,  generators,  and  a  line  frequency  converter.  The  test  article  is 
mounted  in  a  test  tunnel  20  feet  in  diameter  and  65  feet  in  length  with  inlet 
and  discharge  valves  to  permit  control  of  compressor  ratio  and  flow. 

Computer  control  of  all  systems  allows  detailed  study  of  the  test  article  by 
means  of  online  data  analysis.  The  drive  motor  speed,  power  conditioning, 
inlet  and  discharge  valves  and  variable  test  article  geometry  are  all 
digitally  controlled  by  Modcomp  computers.  Test  article  lubrication,  drive 
motor  lubrication,  actuator  hydraulics,  service  air,  cooling  water  and 
auxiliary  air  systems  are  controlled  by  programmable  logic  controllers  (PLC), 
whose  software  is  an  emulation  of  relay  ladder  networks.  Seven  Modcomp 
computers  are  used  for  control,  data  acquisition,  and  operator  interface. 
Facility  and  test  article  control  is  performed  by  four  of  the  Modcomps  (FCC1, 
FCC2,  TAC1 ,  and  TAC2)  which  communicate  through  shared  memory.  Online 
transducer  calibration  and  data  acquisition  is  performed  by  the  DAC  computer 
which  then  sends  data  through  the  auxiliary  computer  (AUX)  to  the  IBM  (Main). 
The  Main  performs  data  acquisition  control,  data  reduction  and  analysis,  data 
display,  and  offline  support  functions.  Operator  interface  is  performed  by 
the  Monitor  computer.  It  allows  the  operator  to  give  commands  to  the  control 
computers  and  the  DAC,  and  also  receives  data  from  them  which  is  stored  on 
historical  tapes  and  displayed  to  the  operator  using  Ramtek  graphics 
generators. 
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The  simulator  computer  is  a  Modcomp  Classic.  It  digitally  simulates  the 
facility  and  the  PLCs  in  real  time  and  provides  feedback  to  the  control 
computers.  Functionally,  the  operators  see  no  difference  between  a  real  and  a 
simulated  test  run.  The  simulator's  functions  are  to  validate  software  and  to 
train  facility  operators.  For  the  validation  function,  all  applications 
software  in  the  CRF  facility  computers  must  be  kept  identical  to  that  of  the 
real  system.  This  is  accomplished  through  the  modification  of  operating 
system's  device  handlers  to  route  control  and  feedback  input/output  (I/O)  to 
the  simulator  computer. 

This  contract  included  the  eleven  tasks  listed  below: 

Task  A  -  Support  to  Facilities 

Task  B  -  Simulator  Support 

Task  C  -  Completion  of  Simulator 

Task  D  -  Data  Acquisition  System  Support 

Task  E  -  Monitor  Computer  Operating  Systems  Upgrade 

Task  F  -  Online  Diagnostics 

Task  G  -  PLC  Simulation 

Task  H  -  Graphics  Response  Time 

Task  I  -  Frequency  Converter  Control 

Task  J  -  Software  Configuration  Maintenance  Support  System 
Task  K  -  Main  Computer  Support 


The  following  Battelle  personnel  worked  on  this  project;  D.  Engler,  D. 

Haller,  D.  Hughes,  R.  Daniel,  P.  Teets,  G.  Potter,  R.  Finkbine,  R.  Luce,  W. 
Kaiser,  M.  Zel inski,  M.  Koenig,  R.  Byers,  W.  Drozda,  N.  Tenuta,  C.  Jones,  M. 
Heltzel,  C.  Derringer,  D.  Molnar,  J.  Pittenger,  N.  Ackgerman,  R.  Mazey,  K. 
Schrieber. 

In  the  sections  that  follow,  each  task  is  addressed  in  three  parts.  The  first 
is  an  overview  that  gives  background  and  general  information  about  the  task. 
The  second  is  the  requirements  for  the  task  as  stated  in  the  contract.  The 
third  describes  accomplishments  on  the  task  and  the  results  obtained  (e.g., 
software  written,  support  given,  people  trained).  The  numbers  in  parentheses 
associated  with  the  various  tasks  and  subtasks  refer  to  specific  paragraphs  in 
the  contract. 
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TASK  A  -  SUPPORT  TO  FACILITIES  (4.1) 


OVERVIEW 

The  facilities  in  the  Technology  Branch  require  continuing  software  and 
hardware  maintenance  to  keep  them  operational.  The  facilities  are  designed  to 
be  versatile;  however,  each  new  test  article  requires  modifications  to 
software  and  interfaces,  and  often  requires  the  addition  of  new  functions. 

The  computers  interface  to  many  pieces  of  equipment.  When  this  equipment  was 
added,  deleted,  upgraded,  or  modified,  software  and  computer  interfaces  often 
required  a  corresponding  adjustment.  Occasionally,  while  running  the 
facility,  it  is  determined  that  software  modifications  were  required  because  a 
function  did  not  meet  its  specification  or  the  specification  did  not  meet  the 
needs.  There  were  many  cases  where  improvements  were  made  to  Increase  the 
efficiency  of  the  facility  operation.  The  software  maintenance  ranged  from 
small  "one-line"  changes  to  complete  redesign  and  rewriting  of  large  sections 
of  code.  This  work  included  support  of  closed  loop  digital  control;  data 
acquisition,  reduction,  and  storage;  transducer  calibration,  device  handlers, 
operating  systems,  database  management,  communications,  and  PLC  relay  ladder 
diagrams.  The  facility  software  is  very  critical,  with  high  interaction 
between  modules  among  all  the  computers.  For  this  reason,  all  maintenance  and 
enhancement  work  was  performed  with  prior  approval  of  the  Air  Force. 

The  specific  requirements,  Battelle's  efforts,  and  the  results  achieved  are 
detailed  by  subtask  in  the  subsections  that  follow. 


Maintain  and  Repair  Software  (4.1.1) 


REQUIREMENTS 

The  contractor  shall  maintain  and  repair  software  in  the  Branch  facilities  as 
approved  by  the  Air  Force  project  engineer  or  his  designee.  The  Air  Force 
will  supply  the  CRF  Operations  and  Maintenance  (O&M)  Manual  to  the  contractor. 
The  contractor  shall  update  the  CRF  O&M  Manual  as  required  to  keep  it  current 
as  a  result  of  the  contractor's  maintenance  and  repair  work. 


BATTELLE  ACTIONS  ANO  RESULTS 
Documentation  and  Training 

Battel le  staff  created  and  updated  documentation  related  to  the  tasks  and 
subtasks  performed  under  this  contract.  Computer  user  notes,  operator  notes, 
and  CRF  Operation  and  Maintenance  documentation  were  updated. 

Battel le  staff  developed  a  new  outline  and  structure  for  CRF  documentation 
based  on  the  original  Cadre  and  vendor  documentation,  CRF  design  notes,  and 
acceptance  test  procedures.  As  new  documentation  was  generated,  it  was 
written  to  comply  with  the  new  structure  and  format.  Some  of  the  existing 
documentation  was  converted  to  the  new  format. 
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Training  was  provided,  at  Battelle's  expense,  for  Battelle  on  site  employees 
to  enhance  skills  necessary  to  efficiently  accomplish  tasks  related  to 
testing.  Masscomp  (Unix  and  RTU)  and  Modcomp  training  courses  were  attended 
as  well  as  the  OEC  GKS  graphics  course.  Membership  was  held  in  Modcomp's  User 
Group  (MUSE)  and  annual  meetings  were  attended  to  stay  current  with  Modcomp's 
new  equipment  releases  and  old  equipment  support.  Battelle  in-house  software 
engineering  and  IBM  MVS  courses  were  attended  as  well  as  the  University  of 
Tennessee  Space  Institute's  aeropropulsion  course. 

Battelle's  CRF  on  site  team  provided  training  for  Air  Force  personnel  and 
other  CRF  contractors.  IBM  MVS  training,  which  included  an  introduction  to 
ISPF,  was  set  up  and  presented  many  times  throughout  this  contract.  Modcomp 
training  was  provided  on  day-to-day  operations,  procedures,  source  editor 
usage,  general  usage,  and  configuration  standards.  CRF  computer  system 
overview  presentations  were  given  and  day-to-day  open  shop  consultation 
support  was  provided  for  Air  Force  and  other  CRF  contractor  personnel. 


Computer  Software/Hardware  System  Configuration 

Configuration  is  a  major  issue  in  all  computer  systems.  It  is  particularly 
important  in  an  environment  such  as  the  CRF,  where  a  network  of  computers 
share  resources.  Battelle  performed  many  tasks  to  improve  CRF/Modcomp 
configuration. 

Battelle  established  a  standard  Modcomp  Diablo  disk  structure.  The  four 
control  computers  share  resources,  communicate  with  each  other  via  shared 
memory,  and  use  similar  peripheral  devices;  however,  different  disk  structures 
were  being  maintained.  This  led  to  the  inadvertent  deletion  and  mixing  of 
software  and  added  to  the  confusion  of  new  and  infrequent  users.  To  alleviate 
these  problems,  Battelle  designed  and  implemented  a  common  disk  structure  to 
be  used  on  all  of  the  control  computers.  As  part  of  the  disk  structure 
definition,  control  computer  software  was  reviewed  and  cleaned  up,  archiving 
to  tape  that  which  was  no  longer  used. 

A  review  and  cleanup  of  all  Modcomp  computer  disks,  standardization  of  naming 
conventions,  as  well  as  elimination  of  personal  user  source  libraries  and 
software  was  performed.  General  user  source  libraries  were  created.  Backup 
and  restore  procedures  were  generated,  including  documentation  on  how  to  use 
them.  Common  source  libraries  for  both  the  Max  III  and  Max  IV  systems  were 
created. 

Upon  completion  of  the  restructure,  software  trouble  logs  and  log  books  as 
well  as  procedures  on  how  to  use  them  were  established  to  control  software 
changes  on  all  Modcomp  systems. 

In  support  of  the  configuration  standardization  many  Modcomp  routines  were 
cleaned  up  and  enhanced.  User  friendly  interfaces  were  added  where  appropriate 
to  facilitate  the  operators'  use  of  the  systems.  Operator  notes  were  written 
and  modified  on  the  topics  of  system  power  up,  start-up,  power  down  and 
backup,  as  well  as  specialized  procedures.  Job  control  procedures  and  naming 
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conventions  were  standardized  as  much  as  possible  for  Nax  III  and  Max  IV 
systems.  Peripheral  devices  were  standardized  and  the  appropriate  software 
and  sysgen  changes  were  made  (e.g.,  the  test  operators  terminal  was 
replaced). 


Miscellaneous  Support 

Control  software  modifications  were  made  to  disregard  test  termination  values 
other  than  a  normal  stop  when  test  article  speed  was  less  than  five  percent. 

A  market  study  of  protocol  converters  was  performed  in  anticipation  of 
their  use  by  people  outside  of  the  CRF.  It  was  felt  that  work  could  be 
performed  more  efficiently  on  a  terminal  that  operated  like  a  Hasp  workstation 
over  a  dialup  line. 

Software  was  written  for  the  DAC  computer  to  diagnose  data  shifting  problems. 

Support  was  provided  to  General  Electric  to  set  up  the  Simulator  computer  for 
light  probe  testing. 

Battelle  onsite  staff  supported  instrumentation  calibration  in  the  CRF. 
Calibration  software  was  developed  for  the  inlet  discharge  and  stator  vane 
feedbacks  to  support  work  on  the  servo  valve  control  problems.  Online  and 
offline  test  support  was  provided  for  transducer  calibration;  valve  (inlet, 
discharge,  and  stator  vane/stage  bleed)  calibration  and  tuning;  and  facility, 
test  article  and  local  database  modification  and  generation.  This  entailed 
the  operation  of  offline  and  simulation  software  as  well  as  the  development, 
modification  and  execution  of  new  software.  Pressure  calibration  software 
modifications  were  made  to  save  PCAL  raw  data  on  tape  and  allow  the 
post-processing  software  to  route  the  data  from  tape  back  to  the  PCAL 
software. 

The  first  version  of  the  high  speed  interactive  tape  plotting  program  was 
written  by  Battelle  on  FCC1  using  a  Tektronix  terminal  and  PLOTIO  software. 

Security  software  and  procedures  were  written  and  reviewed  to  declassify  CRTs, 
graphic  monitors,  memory,  and  disks  on  the  Modcomp  computers.  The  Monitor 
tape  storage  software  was  modified  to  generate  unclassified  facility 
historical  tapes  during  classified  testing.  Main  classification  and 
declassification  programs,  procedures,  and  documentation  were  tested  and 
reviewed  for  3277  and  2250  terminals,  the  2840  disk  controller,  and  3330  disk. 

Battelle  worked  with  Computer  Data  Systems  Inc.  in  their  development  of  the 
CRF  security  plan.  Questions  were  answered,  drawings  and  listings  were 
generated  and  documentation  was  reviewed. 

Battelle  supported  an  Air  Force  effort  to  evaluate  test  segments  and  the 
ability  to  choose  one  of  the  stator  vane  stage  bleed  schedules  defined  in  the 
Main  database.  According  to  Cadre  documentation  several  schedules  could  be 
defined  in  the  database  and  requested  when  running  test  segments.  Schedules 
were  generated  in  the  database  and  some  preliminary  testing  was  performed. 
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Event  Logging  capabilities  were  enhanced.  The  Texas  Instrument  terminal  was 
replaced  with  a  Zenith  Z100  computer  and  a  communications  package  called 
HyperACCESS  was  purchased,  installed  and  documented.  An  internal  RAH  disk  was 
created  on  the  Z100  computer  to  allow  for  buffering  of  messages. 

PLC  translation  software  resides  on  the  Monitor  computer  and  requires  input 
documentation  data.  Battel le  created  and  documented  procedures  that  would 
allow  the  facility  engineers  to  update  the  file  on  their  Zenith  Z100  computer 
and  then  transfer  it  to  the  IBM.  Battel le  also  wrote  procedures  to  create  a 
Modcomp  800  BPI  tape  on  the  IBM  for  use  as  input  to  the  PLC  translation 
software  on  the  Monitor. 

Monitor  software  associated  with  the  diesel  generator  and  Building  71B 
instrumentation  monitoring  was  removed.  This  hardware  is  now  PLC  controlled. 

Monitor  Magnetic  Tape  Storage  software  was  modified  to  add  capabilities  to  set 
alarm  bits  to  inform  test  operators  through  color  graphics  when  tape  drives  go 
off  line. 

Monitor  Playback  software  was  modified  to  allow  users  to  print  data  from  tapes 
that  are  not  the  first  in  a  series.  Capabilities  were  also  added  to  read  the 
facility  database  from  disk  if  it  is  unavailable  on  tape  or  in  memory  and  to 
print  all  1500  variables  if  the  'print'  option  is  selected. 

The  option  of  replacing  the  AUX  computer  with  a  fiber  optic  link  was 
discussed.  Software  and  functions  which  would  need  to  be  relocated  were 
discussed,  fiber  optic  vendors  were  contacted.  This  task  was  then  assigned 
to  the  contractor  who  provided  IBM  support.  All  information  was  given  to 
them  and  they  generated  a  report. 

The  barometric  pressure  reading  was  added  to  the  digital  data  transferred  from 
the  DAC  to  the  Main. 

Software  modifications  were  made  to  several  of  the  control  computer  display 
software  routines.  Data  was  reorganized,  removed,  and  corrected  as  necessary. 

Ten  Wanco  disk  packs  were  purchased  for  the  CRF  Modcomp  computers  to  support 
software  development. 

Battelle  provided  software  support  for  facility  modifications  to  macro/micro 
sequences.  This  entailed  making  changes  to  the  software  which  controlled  the 
sequences,  the  actual  sequence  software  and  sequence  chart  software. 

DAC  global  common  was  decreased  in  size  and  software  was  written  in  the  DAC  to 
resolve  a  problem  related  to  the  reading  number  being  set  to  zero. 

The  STEP  program  was  converted  into  a  database,  was  installed  on  a  Zenith  Z100 
computer  using  dBASE  II,  and  was  expanded  to  include  functions  from  a 
LMCA-developed  dBase  program.  Programs  and  reports  were  written  as  well  as 
data  loaded. 


Battel le  worked  with  the  compressor  test  group  to  verify  thermocouple 
correction  software,  verify  static  stem  and  mach  number  correction  software, 
design  a  new  data  engineer  database  parameter  display  to  provide  capabilities 
to  view  additional  data,  and  verify  calculated  data  going  into  PERF. 

Scan  table  setup  problems  were  identified  and  resolved  which  accounted  for  the 
generator  voltage  being  overwritten  in  FCC2. 

Battel le  compared  arithmetic  calculation  speeds  of  a  Modcomp  II  and  a 
Classic  to  verify  a  vendors  documentation.  The  results  showed  that  the 
Classic  performed  floating  point  arithmetic  four  times  faster  then  a  Modcomp 
II  and  integer  arithmetic  three  times  faster.  Air  Force  personnel  selected  a 
version  of  the  control  computer  Servo  software  to  be  used  to  perform  this 
test.  Battel le  has  built  upon  this  software  to  develop  a  benchmark  program 
which  is  being  used  as  part  of  the  CRF  computer  replacement  study. 


Critical  Channel  Implementation 

Critical  Channel  capabilities  were  implemented.  This  included  four  tasks  and 
incorporated  IBM  and  Modcomp  computer  support.  The  four  tasks  were 
elimination  of  PCAL/Channel  Check  interference,  network  handshaking,  color 
graphics  modifications,  and  limit  check  downloading  and  execution. 

PCAL/Channel  Check  interference  refers  to  PCALs  and  Channel  Checks  interfering 
with  the  online  acquisition,  reduction  and  display  of  monitor  data.  PCALs  and 
Channel  Checks  were  previously  performed  when  the  CRF  was  not  testing  so  the 
inability  to  acquire,  reduce,  and  display  monitor  data  simultaneously  was  not 
a  problem.  The  implementation  of  critical  channels  required  the  ability  to 
recalibrate  certain  channels  while  the  test  was  in  progress.  PCALs  take 
approximately  20  minutes  while  channel  checks  take  four  to  five.  It  was 
unacceptable  to  be  without  monitor  data  for  these  lengths  of  time.  To 
overcome  the  interference  problem  Battelle  created  a  new  area  in  global  common 
on  the  DAC  computer  for  monitor  mode  formats,  allowing  for  the  execution  of  a 
PCAL  or  channel  check  format  and  the  monitor  format  simultaneously. 
Modifications  were  made  to  Main  run  time  software  to  allow  it  to  acquire, 
reduce,  and  display  monitor  data  if  it  was  sent  from  the  DAC  in  between  PCAL 
or  channel  check  data  points. 

Network  handshaking  was  another  task  required  to  support  the  implementation  of 
critical  channels.  Network  handshaking  is  performed  on  the  Modcomp  computer 
with  CRFNET  custom  communications  software.  CRFNET  allows  messages  to  be  sent 
from  one  task  to  another  through  the  computer  architecture.  There  are  also 
other  computer  links  in  the  network  that  do  not  use  the  standard  CRFNET 
protocol.  The  DAC/AUX/Main,  TAC1/DAC,  and  FCC2/Simulator  links  all  have  their 
own  special  purpose  protocols  and  software. 

It  is  important  for  the  operator  and  some  of  the  tasks  to  know  the  status  of 
the  computers  and  links  in  the  CRF  network  during  facility  testing. 

The  previous  network  handshaking  scheme  involved  periodic  messages  from  FCC1 
to  Monitor,  and  Monitor  to  DAC  only.  Other  messages,  such  as  Preston  status 
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and  DAC/AUX  link  status,  were  sent  to  the  Monitor  only  when  a  status  changed. 
There  were  several  problems  In  the  design. 


-  The  Monitor  computer  did  not  know  whether  the  Main  was  up. 

-  If  the  Monitor  was  rebooted,  It  would  not  know  whether  the  AUX  was  up 
because  the  DAC  only  sent  an  AUX  status  message  when  the  status  changed. 

-  The  DAC  did  not  know  whether  the  AUX  was  up  unless  It  was  currently  In 
acquisition  mode. 

-  If  the  DAC/AUX/Maln  link  went  down,  It  was  not  easy  to  determine  which 
link  or  computer  was  down. 

-  The  only  way  to  tell  whether  the  TAC1/DAC  link  was  working  was  to  see  If 
acquired  data  was  changing. 

-  On  several  occasions,  problems  were  experienced  while  Initializing  the 
DAC  and  Monitor  because  of  two  special  messages  that  were  sent  from  DAC 
to  Monitor  and  Monitor  to  DAC.  It  Is  possible  for  the  receiver  of  a 
message  to  get  the  message  correctly  while  the  sender  detects  an  error. 
(The  final  ACK  has  an  error  seen  only  by  one  side).  It  was  discovered 
that  the  DAC  sent  an  Initialization  message  which  the  Monitor  received, 
but  since  the  DAC  detected  an  error,  It  kept  retrying.  Meanwhile,  the 
Monitor  no  longer  had  a  receive  queued,  and  It  was  trying  to  send  a 
message  to  the  DAC. 

-  If  the  Monitor  was  rebooted  while  the  DAC  was  taking  data,  the  lights  at 
the  data  engineers  station  would  not  indicate  what  formats  were  selected 
and  running. 

The  new  scheme  developed  by  Battel le  Incorporated  the  following  changes: 

-  Deleted  initialization  messages  between  DAC  and  Monitor. 

-  Generated  a  message  from  DAC  to  Monitor  every  5  seconds  containing: 

--  Running  format  number, 

--  Selected  formats, 

--  Selected  transient  time, 

--  Current  mode  lights,  and 

--  Status  of  Preston,  TAC1  link,  and  DAC/AUX/Maln  link. 

-  Generated  a  message  from  AUX  to  DAC  every  7  seconds  (If  not  acquiring 
data)  containing  status  of  Main. 

-  Generated  a  message  from  AUX  to  Main  every  7  seconds  (If  not  acquiring 
data)  containing  status  of  DAC. 

-  Generated  a  message  from  Main  to  Monitor  every  10  seconds  containing 
status  of  DAC  and  AUX. 

-  Retained  FCC1  to  Monitor  handshaking. 
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-  Modified  color  graphics  display  number  2  to  show  status  of  links  as  well 
as  status  of  computers. 

One  problem  encountered  using  the  new  scheme  was  that  whenever  the  AUX  had  a 
WRITE  queued  to  the  Main  and  the  Main  did  not  have  a  READ  queued  (because  the 
real  time  software  was  not  running),  the  Main  spent  50  percent  of  its  CPU  time 
servicing  interrupts  from  the  AUX.  (The  AUX  is  also  very  busy  servicing 
interrupts  from  the  Main.)  To  alleviate  this  problem,  the  AUX  now  terminates 
its  WRITE  after  12  seconds  and  never  tries  again  until  the  data  engineer 
requests  a  reading. 

The  Monitor  color  graphics  task  required  that  the  display  of  critical  channels 
be  redesigned  and  modified  to  incorporate  the  new  channels.  Color  graphics 
displays  related  to  computer  communications  were  enhanced  and  modified  to 
include  the  additional  data  now  available  from  the  new  network  handshaking 
scheme. 

Critical  channel  limit  checking  was  the  fourth  task.  Critical  channel  limits 
are  input  into  the  Main  database  as  engineering  units  values.  They  are  then 
converted  to  counts  by  using  the  scale  factors  stored  in  the  Main  database 
before  being  downloaded  to  FCC1.  The  actual  limit  checking  of  the  critical 
channels  is  performed  by  the  FCC1  computer.  Problems  were  encountered  in  the 
engineering  units  to  counts  conversion  being  performed  on  the  Main.  This 
portion  of  the  task  was  being  performed  by  Air  Force  personnel. 

Some  of  the  critical  channels  are  thermocouples  which  measure  a  temperature 
difference  rather  than  an  absolute  temperature.  This  means  that  the  alarm 
limits  in  terms  of  counts  may  need  to  change  during  the  day  as  the  reference 
temperature  changes.  Battel le  developed  software  that  would  allow  the  data 
operator  to  have  the  limits  recalculated  and  downloaded  whenever  the  data 
engineer  judges  that  the  reference  temperature  has  changed  significantly. 

Battelle  enhanced  the  logic  that  downloads  the  test  article  and  critical 
channel  limit  check  databases.  A  download  is  requested  by  FCC1  when  the 
Monitor  computer  notifies  it.  Downloads  are  requested  when  panel  2  is  armed 
in  Facility  mode  or  when  the  test  operator  enters  a  CCD  command.  If  an  error 
is  encountered  FCC1  will  request  it  again.  A  time  out  option  is  exercised  if 
the  Main  doesn't  respond  within  a  user  defined  amount  of  time. 


Facility  Historical  Data  Storage 

Monitor  facility  historical  data  storage  software  was  restructured  for  the 
following  reasons: 

-  It  was  aborting  and  a  dump  analysis  showed  that  a  region  of  memory 
(about  300  contiguous  words)  was  getting  set  to  zero,  with  no  clue  as  to 
where  the  problem  was. 

-  Whenever  the  task  aborted,  a  very  complicated  procedure  had  to  be 
performed  to  restart  it. 
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-  On  Initialization,  the  initialize  magnetic  tape  command  was  frequently 
forgotten,  with  the  consequence  that  the  task  tried  to  read  to  the  end 
of  an  uninitialized  tape  and  got  parity  errors.  The  only  way  to  recover 
was  to  manually  abort  the  task. 

-  Data  was  being  lost  while  switching  tapes. 

-  A  possible  tape  stall  after  every  write  was  not  checked. 

-  The  logic  was  difficult  to  understand  because  the  task  was  a  single 
module  and  was  not  well  structured. 

The  task  was  divided  into  4  modules.  The  Initialization  task  was  modified  to 
no  longer  require  initialization  of  a  tape.  The  only  time  the  operator  might 
not  want  to  initialize  a  tape  would  be  if  the  computer  had  halted  during  a 
compressor  test,  leaving  the  tape  not  closed.  To  handle  this  rare  event, 
commands  were  added  in  the  initialization  task  to  close  and  dismount  a  tape, 
while  automatically  initialize  the  first  tape  as  soon  as  It  started. 

The  problem  of  losing  data  between  tapes  was  caused  by  the  fact  that  Modcomp 
does  not  provide  for  a  program  to  know  when  a  tape  has  finished  rewinding. 

The  standard  rewind  subroutine  returns  immediately  with  the  user  file  table 
busy  bit  reset.  In  order  to  cope  with  this,  the  software  was  modified  to 
issue  a  rewind,  then  immediately  follow  it  with  a  write  of  the  new  directory, 
and  set  up  the  tape  stall  alarm  to  occur  if  the  write  does  not  complete  within 
the  time  it  takes  to  do  a  rewind. 


Monitor  Color  Graphics  Support 

One  of  the  primary  Monitor  computer  functions  is  to  provide  test  personnel 
with  real  time  information  on  the  facility  and  the  test  article.  The  color 
graphics  system  is  the  primary  vehicle  for  providing  an  adequate  amount  of 
data  in  a  timely,  reliable  manner.  At  the  CRF  this  Is  accomplished  with  a 
hardware  system  consisting  of  two  Ramtek  graphics  controllers,  with  four  color 
monitors  each,  connected  to  the  Monitor  computer  system. 

The  supporting  software  of  the  color  graphics  system  Is  based  on  a  unique 
processor  written  for  the  CRF  called  the  Command  String  Processor  (CSP).  The 
purpose  of  this  package  was  to  create  an  easily  used  Interface  to  the  Ramtek 
graphics  Instructions.  Other  software  routines  and  procedures  assist  in  the 
testing  of  the  display  software,  loading  and  storing  of  data  files,  and 
general  use  of  the  system. 

Each  display  screen  in  the  CRF  is  divided  into  a  background  and  a  real  time 
portion.  This  allows  the  background  to  remain  on  the  screen  after  being 
placed  there  when  the  display  is  first  selected.  Each  update,  then,  requires 
writing  only  the  changing  data,  thereby  reducing  the  amount  of  the  screen  that 
must  be  written  with  each  update.  This  background  task  Is  stored  on  the 
Monitor  computer  disk  as  compiled  Ramtek  code,  which  only  requires  downloading 
to  the  Ramtek  controllers. 
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Most  of  the  software  for  the  graphics  displays  is  written  in  a  high  level 
language  consisting  predominantly  of  FORTRAN  with  "macro"  calls  that  are 
translated  to  standard  FORTRAN.  Some  of  the  background  tasks,  however,  are 
stored  as  data  files  in  an  established  format.  These  files  are  used  as  input 
to  other  routines,  which  allow  the  designer  to  easily  view  the  display  as  it 
is  changed.  The  online  graphics  task  performs  the  following  functions: 

-  Check  the  display  selection  for  each  screen, 

-  Maintain  the  "annunciator"  portion  of  the  screen  that  flags  alarms  and 
warnings  in  the  various  displays, 

-  Activate  the  downloading  of  the  background  portions  of  the  selected 
displays  to  the  Ramtek, 

-  Load  and  activates  the  dynamic  portion  of  the  display. 

When  a  display  screen  is  selected,  the  background  portion  of  the  display  is 
downloaded  to  the  proper  Ramtek  controller  and  displayed  on  the  color  monitor. 
The  task  that  constructs  the  dynamic  portions  of  the  display  is  brought  into 
the  Monitor  computer's  memory.  The  necessary  calculations  to  display  the  data 
are  made,  and  it  is  then  passed  along  with  display  Information  to  the  Ramtek 
controllers.  When  a  display  is  no  longer  selected  for  a  screen,  the  display's 
task  is  removed  from  memory. 

Battel le  has  enhanced  the  color  graphics  package  in  the  following  ways: 

-  Converted  the  software  and  redesigned  it  to  eliminate  the  overlay 
structure  which  is  not  supported  under  the  Max  IV  operating  system. 

-  Made  the  refresh  tasks  resident  in  memory  to  increase  the  speed  and 
decrease  the  number  of  disk  accesses. 

-  Purchased  new  Ramtek  units  to  speed  up  the  present  graphics  rate  and 
allow  for  the  use  of  additional  monitors. 

-  A  great  deal  of  display  work  was  done,  both  in  the  addition  of  new  and 
the  modification  of  existing  displays. 

-  Helped  to  establish  a  generic  compressor  map  for  Monitor  display. 

-  Made  extensive  modifications  to  the  annunciator  program  to  reduce  the 
number  of  checks  required  to  find  a  fault  in  a  display  and  eliminated 
multiple  bit  checks.  Also,  established  a  table  check  for  bits  reset. 

-  Improved  and  expanded  the  Interactive  Graphics  Processor  (IGP).  Replaced 
use  of  Modcomp  front  panel  switches  with  commands.  New  commands  were 
added  to  shift  and  duplicate  portions  of  displays.  Commands  to  clear  and 
preset  displays  were  enhanced. 

-  Worked  with  facility  personnel  to  enhance  efficiency  of  displays. 
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-  Worked  with  facility  personnel  toward  establishing  standards  for 
representing  data. 


Classified  Data  Tracking 

The  classified  tracking  task  deals  with  the  way  in  which  printouts,  displays, 
and  graphics  are  defined  and  labeled  as  to  their  appropriate  classification. 
The  present  system  results  in  some  printouts  and  displays  being  generated 
which  have  classified  labels,  but  In  fact  are  not  classified. 

Battelle  compiled  and  documented  the  requirements  to  provide  classified  data 
tracking.  We  then  evaluated  the  options  available  to  meet  the  requirements, 
selected  the  best  alternative  and  documented  the  actual  steps  and  effort 
needed  to  Implement  it. 


Power  Monitoring 

Electric  companies  bill  large  power  users  (such  as  Wrlght-Patterson  Air  Force 
Base)  not  only  by  energy  used,  but  also  by  peak  power  demand  averaged  over 
30-minute  Intervals.  The  electric  company  must  maintain  the  capacity  to 
supply  peak  demand  even  though  It  usually  goes  untapped.  It  Is,  therefore, 
very  expensive  to  set  a  new  peak.  The  power  monitoring  system  provides  a 
method  of  early  warning  that  a  peak  Is  about  to  occur  and  displays  either, 
"reduce  power  immediately  to  <a  calculated  value>  "or"  run  at  current  power 
for  <a  calculated  t1me>  before  dropping  to  minimum  speed  for  the  rest  of  the 
30-minute  period. 

The  power  for  the  base  Is  monitored  by  a  computer  which  sends  Information  over 
modems  to  several  different  facilities.  The  messages  are  sent  every  30 
seconds  and  contain  the  amount  of  energy  used  since  the  last  message,  the  time 
remaining  in  this  30-minute  period,  and  an  estimate  of  the  total  energy  that 
will  be  used  In  this  30-minute  period. 

The  computer  system  was  in  place  prior  to  the  start  of  this  contract;  however, 
it  did  not  completely  serve  all  the  CRF's  needs. 

To  adequately  monitor,  predict,  and  document  power  usage,  Battelle  designed 
and  Implemented  a  power  monitoring  package  consisting  of: 

-  A  program  that  read  the  modem  data  and  checked  it  for  errors. 

-  A  program  that  calculated: 

-  the  CRF  component  of  base  power  usage  (from  once/second  data 
collected  by  FCC1), 

-  the  background  power  usage  (power  consumed  by  all  other  users) 
averaged  over  the  last  4  minutes, 
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-  the  time  remaining  in  which  the  CRF  could  continue  to  run  at  present 
power  before  dropping  to  minimum  speed  in  order  to  avoid  a  peak,  and 


-  the  power  the  CRF  would  have  to  use  in  order  to  maintain  constant 
power  and  still  avoid  a  peak. 

-  A  graphics  program  to  show  total  base  and  CRF  energy  usage  as  a 
function  of  time  over  the  current  30-minute  period.  If  we  were  in 
danger  of  setting  a  peak,  an  annunciator  alarm  would  appear  on  every 
graphics  screen,  and  the  power  display  picture  could  be  called  up 
quickly  to  indicate  how  long  the  CRF  could  continue  running  or  to 
what  level  the  speed  should  drop. 

The  existing  facility  historical  data  tape  storage  and  playback  system  allowed 
post  test  analysis  in  the  event  of  a  peak  to  see  whether  it  was  caused  by  the 
CRF. 


Data  Analysis  Graphics 

Battelle  compiled  and  documented  the  requirements  and  options  for  the 
implementation  of  compressor  graphics.  Input  data  would  come  from  the  Main 
reduction  software. 

Battelle  consulted  with  Air  Force  staff  members  who  would  be  potential  users 
of  the  graphics  system,  and  has  generated  a  set  of  requirements  for  the 
graphics  system.  The  requirements  document  the  type  of  data  that  should  be 
available  to  the  graphics  system,  the  types  of  displays  the  system  should  be 
capable  of  generating,  and  how  the  user  will  interact  with  the  software.  The 
capabilities  of  the  software  were  divided  into  what  will  be  needed  in  an 
Initial  system,  and  what  the  future  enhancements  to  the  system  should  be. 

Battelle  evaluated  four  options  for  this  system  which  would  provide  users  with 
the  capability  to  graphically  display  data  from  the  Main  computer's  reduction 
software.  The  four  options  Included  (1)  using  Tektronix  terminals  connected 
directly  to  the  Main  and  the  IBM  graphics  package  DISSPLA,  (2)  downloading 
the  data  to  the  Zenith  248  computer  and  using  It  as  a  graphics  workstation, 

(3)  downloading  data  to  a  DEC  workstation  and  using  it  as  a  graphics 
workstation,  (4)  downloading  the  data  to  a  Masscomp  micro  computer  and  using 
it  as  a  graphics  workstation.  Battelle  wrote  a  report  evaluating  these  four 
options  and  documented  the  DEC  workstation  as  the  best  alternative. 

Battelle  documented  the  new  software,  and  changes  to  the  existing  software 
which  would  be  necessary  to  Implement  a  graphics  system.  Time  estimates  in 
man  hours  were  given  to  complete  the  software  on  the  Main  computer,  and  on  the 
graphics  workstation. 

Battelle  developed  test  software  to  determine  the  feasibility  of  using  the 
Zenith  248  and  the  DEC  workstation  as  a  graphics  work  station.  The  majority 
of  the  software  created  by  Battelle  In  this  effort  will  be  used  in  the  final 
configuration  of  the  graphics  system. 
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Digital  Control  Team 

Three  Battelle  onsite  team  members  were  assigned  to  a  digital  control  team  to 
address  problems  which  could  potentially  Interfere  with  the  successful 
execution  of  F100  testing. 

Test  article  speed  problems  were  diagnosed,  documented  In  Incident  reports, 
and  resolved.  Training  was  provided  to  Air  Force  personnel,  and  trouble  logs 
were  resolved.  The  Battelle  members  also  participated  in  an  extensive 
evaluation  of  the  Variable  Position  Control. 


Variable  Position  Control 

The  CRF  variable  position  control  problems  included  the  following: 

-  One  inlet  valve  was  oscillating  forcefully  against  the  stop, 

-  Another  inlet  valve  was  opening  when  it  should  have  closed, 

-  The  discharge  valve  was  opening  too  quickly  and  hitting  the  stop, 

-  The  stator  vanes  were  not  following  setpoint  closely  enough,  and  control 
was  jerky, 

-  Multiple  feedbacks  on  a  single  stator  vane  were  showing  differences  as 
large  as  eight  degrees. 

An  extensive  review  of  the  software  revealed  numerous  errors:  bad  analog 
output  addresses  and  values,  wrong  variable  names,  incorrectly  dimensioned 
arrays,  irrelevant  code,  and  bad  global  common  addresses.  The  team  also  found 
that  the  tuning  constants  for  the  modified  PID  control  loop  algorithm  were  not 
properly  documented.  Battelle  analyzed  the  code  in  order  to  document  the 
constants,  make  sure  the  algorithm  was  correct,  and  tuned  the  control  loops. 

In  order  to  ascertain  why  the  stator  vane  feedbacks  were  so  far  apart, 

Battelle  supported  the  removal  of  the  potentiometers  to  test  for  linearity  and 
discovered  that  several  of  the  pots  had  loose  connections  internally.  The 
feedback  voltage  showed  spikes  as  the  pots  were  rotated.  After  fixing  the 
software,  replacing  and  recalibrating  the  pots,  and  returning  the  control 
loops,  the  inlet  guide  vane  (I6V)  feedbacks  were  still  far  apart.  When  moving 
the  IGV  from  a  stop,  one  feedback  would  start  moving  immediately,  but  the 
other  two  would  not  change  until  the  first  had  moved  several  degrees.  An 
inspection  showed  that  the  coupling  had  been  damaged  due  to  incorrect 
placement  of  one  of  the  stops.  Since  fixing  the  coupling  would  have  required 
an  intolerable  amount  of  time,  temporary  changes  were  made  to  the  software  to 
control  the  IGV  using  only  the  good  feedback,  while  still  displaying  the  other 
two  feedbacks  for  operator  information  only. 

It  was  necessary  to  calibrate  the  IGV  feedbacks  using  a  nonstandard  procedure. 
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Instead  of  moving  the  IGV  from  stop  to  stop  and  letting  the  computer  calculate 
the  calibration  coefficients,  resistance-versus-angle  measurements  were  used. 
These  measurements  had  been  taken  while  checking  linearity,  along  with  the 
voltage  measured  at  one  stop,  to  calculate  the  coefficients  manually. 

Other  software  changes  were  made  to  ensure  that  the  IGV  went  to  a  safe  stop 
at  the  beginning  and  end  of  a  test.  These  modifications  allowed  successful 
testing  of  the  F100  compressor  unit. 


PLC  Data  Highway 

The  Operations  Group  purchased  an  Allen-Bradley  PLC-2/30  to  replace  the  old 
PLC  #2  (in  the  pit),  so  that  more  functions  could  be  added,  logic  simplified, 
and  trouble-shooting  made  easier.  The  following  problems  were  identified  at 
the  start  of  the  task: 

-  The  PLC-2/30  required  a  different  communications  protocol. 

-  FCC1  didn't  contain  enough  memory  to  support  both  protocols  at  once. 

-  FCC1  wouldn't  be  able  to  write  to  the  same  PLC  addresses  as  before, 
because  all  the  PLC  "input"  words  are  zeroed  out  at  the  beginning  of  each 
cycle.  FCC1  would  now  have  to  write  to  PLC  "output"  words. 

-  Addresses  000-007  and  100-107  (octal)  are  reserved  for  system  use  on  the 
new  PLC,  instead  of  being  used  for  Rack  0  outputs  and  inputs.  Any 
references  to  those  addresses  in  the  ladder  logic,  the  control  computers, 
and  the  Monitor  color  graphics  programs  would  have  to  be  changed. 

In  order  that  only  one  protocol  would  have  to  be  supported,  the  Air  Force 
purchased  a  data  highway  interface  for  the  old  PLC  which  would  allow  it  to  use 
the  new  protocol.  This  required  different  interfaces  for  the  new  PLC  and 
FCC1.  However,  using  a  data  highway  has  some  advantages: 

-  The  PLCs  can  send  data  directly  to  each  other,  instead  of  relaying  it 
through  FCC1. 

-  It  is  possible  to  add  an  intelligent  terminal  in  the  control  room  for 
trouble  shooting. 


The  following  work  has  been  completed  except  for  final  online  testing,  the 
backup/ restore  function,  and  documentation. 

-  Both  PLCs  were  connected  to  the  data  highway,  logic  was  added  to 
send  a  word  from  PLC-2  to  PLC- 1  which  was  previously  relayed  through 
FCC1  and  software  was  written  in  FCC1  to  communicate  with  the  data 
highway,  without  changing  any  PLC  addresses. 
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Several  problems  were  encountered  and  overcome  in  rewriting  the  communications 
software : 


-  It  was  discovered  that  the  old  software  would  hang  up  if  no  reply  was 
received  from  a  PLC,  or  even  if  the  reply  was  one  byte  short.  If  just 
one  of  the  two  PLCs  had  a  problem,  communication  with  both  PLCs  (and  with 
the  Monitor)  would  cease.  This  problem  was  easily  fixed  by  implementing 
a  timeout  of  0.4  seconds  between  sending  a  command  and  receiving  a 
complete  reply.  (The  maximum  time  ever  observed  for  a  good  reply  was 
0.22  seconds,  but  this  may  increase  if  another  device  is  added  to  the 
data  highway.) 

-  It  is  impossible  under  the  new  protocol  to  know  in  advance  how  many  bytes 
will  be  in  a  reply.  This  is  because  any  data  link  escape  in  the  data 
gets  expanded  into  two.  An  input  buffer  of  over  1000  bytes  was  used 

and  is  being  used  today  instead  of  one  half  that  size.  More  importantly, 
this  created  the  next  problem. 

-  Since  there  was  no  special  character  (such  as  a  carriage  return)  to 
indicate  the  end  of  a  message,  a  binary  read  was  used  which  would  not 
complete  until  an  exact  number  of  characters  were  received.  The  first 
scheme  involved  queuing  up  two  reads  so  that  the  second  buffer 
automatically  took  over  when  the  first  was  full,  allowing  a  single 
message  to  span  both  buffers.  Unfortunately,  it  was  discovered  that  the 
hardware  created  noise  at  the  start  of  a  new  buffer. 

-  There  is  a  known  problem  in  Classics  running  MAX  IV  rev  F,  using  models 
4804  and  4806  RS232  controllers,  which  may  cause  a  computer  to  halt 

if  uncompleted  reads  are  terminated.  Upon  receipt  of  the  "abort 
terminate"  command,  the  hardware  generates  an  unexpected  interrupt  which 
the  software  doesn't  properly  handle.  Battelle's  first  scheme  described 
above  was  designed  to  avoid  this  problem,  even  though  it  was  not  known 
whether  it  would  occur  on  a  MAX  III  Modcomp  II  with  a  model  4811  RS232 
controller.  Since  it  did  not  work,  the  software  was  changed  to  issue  a 
terminate  after  each  command/reply  cycle.  Battel le  ran  this 
configuration  for  several  hours  to  see  whether  the  system  would  halt. 

It  did  not.  However,  this  test  will  have  to  be  repeated  when  the  control 
computers  are  replaced  with  Classics  running  Max  IV.  If  the  computer 
does  halt,  two  options  exist.  Going  to  rev  I,  or  modifying  the  handler 
so  that  an  input  buffer  is  used  as  a  circular  buffer  and  is  never 
released. 

-  To  speed  up  communi cat ions,  and  make  the  two  reads  from  a  single  PLC  be 
close  together  in  time,  four  read  commands  were  Issued  at  once  before 
waiting  for  the  reply  to  the  first  command.  However,  the  data  highway 
was  unreliable  under  these  conditions:  12  errors  occurred  out  of  every 
1000  one-second  cycles.  Consultation  with  Allen-Bradley  revealed  that 
the  box  being  used  had  some  noise  problems  and  they  replaced  it  with  a 
later  series  box  which  reduced  the  error  rate  to  about  4  errors  per  1000 
one- second  cycles. 
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-  Logic  was  added  to  the  PLC  communication  subroutine  to  E-trip  if  10 
consecutive  one-second  cycles  had  any  PLC  errors  in  either  reads  or 
writes. 

-  The  main  program  in  FCC1  was  changed  to  E-trip  if  the  one  second  task 
took  more  than  3  seconds  to  do  its  "one-second"  work.  (It  previously 
tripped,  if  it  took  1.5  seconds.) 

-  There  are  two  ways  to  send  data  to  a  PLC:  "word"  writes  and  "bit" 
writes.  Word  writes  can  write  to  several  addresses  with  one  command,  but 
only  if  the  addresses  are  consecutive.  Bit  writes  can  write  to  scattered 
addresses  with  a  single  command,  but  are  slightly  less  efficient  if  only 
one  word  needs  to  be  written.  The  PLC  communication  subroutine  was 
changed  to  use  bit  writes  Instead  of  word  writes,  making  it  faster  if 
multiple  words  need  to  be  written. 

It  takes  about  0.74  seconds  to  read  all  the  data  from  both  PLCs.  If  all  nine 
words  need  to  be  written,  then  it  takes  a  total  of  1.09  seconds  to  do  the  I/O 
(not  counting  limit  checking  and  sending  the  data  to  the  Monitor). 

The  following  tasks  remain  to  be  accomplished  to  complete  the  implementation 
of  the  new  PLC  configuration. 

-  Reconfigure  the  I/O  racks,  the  ladder  logic,  and  the  Modcomp  software  so 
the  old  PLC  uses  the  same  addresses  as  the  new  PLC.  This  allows  the  CRF 
to  fall  back  to  the  old  PLC  simply  by  moving  the  I/O  racks  without 
moving  any  individual  I/O  cards. 

-  Write  the  ladder  logic  for  the  new  PLC. 

-  Replace  the  old  PLC  with  the  new  one. 

-  Purchase  software  to  display,  modify,  and  print  ladder  logic.  (The 
Modcomp  software  that  is  currently  used  to  print  ladder  diagrams  would 
have  to  be  modified  extensively  to  work  with  the  new  PLC,  and  it  would 
not  be  cost  and  time  effective.) 


Configuration  Codes 

IBM  and  Modcomp  software  modifications  were  made  to  enhance  the  implementation 
of  configuration  codes.  Test  Article  speeds  which  are  calculated  in  the  TAC 
computer  are  sent  to  the  DAC  as  digital  data.  The  distortion  screen,  build 
number  and  test  segment  related  configuration  codes  are  entered  from  the 
Monitor  test  operator's  station  and  sent  to  the  DAC.  The  DAC  sends  the  entire 
set  of  codes  to  the  Main  computer  where  they  are  incorporated  in  the  tape 
directory. 
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Transient  Data  Acquisition 

Transient  data  is  data  taken  from  the  compressor  while  some  aspect  of  its 
performance  is  changing.  A  paper  was  written  by  Air  Force  personnel  on 
transient  data  acquisition.  This  capability  was  part  of  the  original  design 
of  the  CRF  but  was  never  totally  implemented  by  Cadre.  Problems  which 
Battel le  resolved  were: 

-  The  DAC  was  running  an  operating  system  which  limited  it  to  64k  words  of 
memory.  This  meant  that  the  DAC  could  not  buffer  scans,  but  had  to  send 
them  one  at  a  time  to  the  AUX,  which  reblocked  them  before  relaying  them 
to  the  Main.  If  the  system  had  worked,  it  would  have  been  much  slower 
than  the  present  package,  because  of  this  DAC/AUX  link  bottleneck. 

-  The  AUX  software  was  written  in  such  a  way  that  it  needed  to  know  the 
size  of  buffers  before  they  were  sent,  so  that  it  could  queue  up  multiple 
READS  using  consecutive  blocks  of  memory.  This  involved  some  extra 
handshaking,  which  did  not  work  very  well  due  to  poor  error  recovery 
logic,  and  because,  when  the  buffer  size  changed,  all  the  READS  to  the 
link  had  to  be  terminated,  which  frequently  caused  errors  on  the  other 
side. 

-  An  end-of-reading  flag  was  supposed  to  be  set  in  the  last  scan  as  a 
signal  to  the  AUX  to  terminate  the  unused  reads  and  start  a  new  sequence. 
If  an  error  occurred  on  the  last  scan,  however,  both  the  AUX  and  the  Main 
would  lock  up. 

-  Even  if  the  end-of-reading  flag  made  it  safely  to  the  Main,  it  was  missed 
because  the  Main  was  looking  for  it  in  the  first  scan  of  each  buffer 
instead  of  the  last. 

-  Major  portions  of  the  code  in  both  the  Main  and  the  AUX  were  written  in 
assembly  language  and  were  extremely  complicated.  For  example,  one  huge 
program  in  the  Main  handled  both  Monitor  and  AUX  links,  although  the 
protocols  and  the  uses  of  the  data  were  quite  different. 


To  fix  these  problems  and  get  the  transient  data  system  running  in  its  present 
efficient  and  reliable  manner,  Battelle  performed  the  following: 

-  Upgraded  the  DAC  operating  system  from  Max  III  to  Max  IV. 

-  Rewrote  most  of  the  data  collection  and  transmission  program  in  the  DAC 
so  that  it  filled  up  a  32k  byte  buffer  before  sending  it  to  the  AUX. 

-  Eliminated  the  DAC/AUX  buffer  size  handshaking.  The  AUX  now  queues  up 
two  32k  byte  READS  and  determines  how  many  bytes  it  received  after  a  READ 
completes. 
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-  Rewrote  the  Main  software  that  controlled  the  Monitor  and  AUX  links  to 
create  separate  small  assembly  language  modules  to  send  the  channel 
commands  to  the  links,  and  FORTRAN  programs  to  handle  Monitor  link 
messages,  data  acquisition  buffer  handling,  and  tape  storage. 

Once  the  transient  data  software  system  was  verified  to  be  working  as 
required,  the  hardware  was  evaluated  further. 

Battelle  wrote  several  offline  diagnostics  to  be  run  every  morning  before  a 
compressor  test.  The  first  diagnostic  required  making  up  a  special  patch 
panel  to  patch  a  single  voltage  source  (which  was  a  sine  wave)  into  all  the 
channels  simultaneously.  For  each  channel,  the  program  reads  that  channel  and 
another  channel,  first  consecutively,  then  separated  by  ten  other  channels. 

It  does  this  100  times  and  calculates  the  average  absolute  difference  between 
the  two  channels  each  way.  If  the  "hold"  feature  is  operating  properly,  the 
average  differences  will  be  about  the  same.  Otherwise,  the  difference  between 
the  two  channels  read  ten  channels  apart  will  be  much  greater  than  when  read 
consecutively. 

Other  diagnostics  were  written  to  test  the  relative  calibrations  between  the 
two  amplifiers  on  each  card  and  to  test  the  "droop"  rate. 

The  sample  and  hold  diagnostics  immediately  proved  their  worth  by  showing  that 
approximately  half  of  the  cards  had  failed  in  some  way.  The  new  software  was 
also  essential  to  the  effort  in  calibrating  the  amplifiers. 

To  support  the  Transient  Data  Acquisition  task  defined  in  Task  K,  several 
software  modifications  were  required  on  the  Modcomp  computers.  These 
modifications  included: 

-  Writing  software  to  determine  the  speeds  attainable  for  the  Main  link, 
the  serial  link,  and  the  Preston  with  various  buffer  sizes. 

-  Many  changes  were  made  to  DAC  software  to  speed  up  statics  and 
transients. 

-  AUX  software  was  rewritten  to  interface  and  work  with  the  new  DAC 
software. 

-  The  Main  buffering  scheme  was  modified  and  streamlined  to  achieve  a  rate 
of  four  megabytes/second. 


Stator  Vane/Stage  Bleed  Expansion 

The  stator  vane/stage  bleed  expansion  project  was  started  by  the  Air  Force. 
Battelle  then  supported  their  effort  by  participating  in  the  design  review. 
Support  was  provided  to  make  the  necessary  database  modifications,  recreate 
and  enlarge  the  direct  access  files  required,  and  participate  in  testing  and 
resolution  of  hardware  problems. 
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Global  Common  Database 


Battel le  designed  and  partially  Implemented  the  Global  Common  (GCOM)  Database 
to  assist  In  Modcomp  software  design,  development,  and  documentation. 

Tasks  within  the  CRF  computers  communicate  with  each  other  by  sharing  global 
regions  and,  if  in  separate  computers,  through  a  communication  task.  Shared 
global  commons  are  used  by  both  of  these  means. 

In  the  current  environment,  standards  have  not  been  established  as  to  the  use 
and  definition  of  these  areas.  GCOM  will  help  a  programmer  identify  and 
understand  the  interrelationships  and/or  interdependencies  between  routines 
using  a  global  shared  region.  It  will  also  aid  in  the  development  of 
standards  for  global  common  use.  It  will  assist  Modcomp  programmers  in  all 
facets  of  software  development  by  allowing  them  to  search  for  and  list  data 
based  on  various  parameters  as  well  as  update  and  print  database  reports. 

Battel le  defined  the  requirements,  designed,  implemented,  and  documented  the 
GCOM  database  system.  Its  development  was  based  on  the  use  of  the  Enable 
database  software. 


Modcomp  Operating  System  Upgrades 

Modcomp  operating  system  upgrades  from  Max  III  to  Max  IV  were  performed  on  the 
DAC  and  Monitor  computers.  All  custom  device  handlers  were  modified  as  well 
as  the  communications  software.  Software  bugs  found  in  the  Modcomp  terminal 
handler,  the  interrupt  logic,  and  the  abort  logic  were  resolved.  Disk  drives 
were  restructured  and  all  handlers  and  interrupt  routines  were  modified  to 
interface  with  the  new  file  structures.  Max  III  operating  system 
modifications  were  eliminated. 

Disk  drive  problems  were  encountered  with  the  Monitor  computer  as  part  of  the 
upgrade.  Further  investigation  isolated  the  problem  to  the  disk  drives 
handling  of  load  modules  which  span  track  boundaries.  The  Max  III  operating 
system  performs  reads  as  sector-to-sector  transfers,  Max  IV  reads  by  DMP 
chaining.  The  disk  drive  was  also  found  to  be  incompatible  with  other  disk 
drives  in  the  CRF  and  laboratory;  it  was  temporarily  replaced  with  a  borrowed 
disk  drive. 

Tasks  that  were  originally  set  up  as  overlays  were  restructured  because  Max 
IV  doesn't  support  overlays. 

Communication  software  was  converted  to  Max  IV  and  problems  were  resolved  as 
they  were  found  and  identified.  Many  idiosyncrasies  in  Max  III  became  major 
problems  with  the  installation  of  Max  IV.  Battelle  modified  DAC/AUX  protocol 
to  allow  the  link  to  recover  from  errors.  Software  was  written  for  the 
Monitor  and  AUX  to  keep  Main  links  from  timing  out.  Data  buffer  sizes  were 
increased  in  the  DAC  to  decrease  the  frequency  of  DAC/AUX  link  errors. 
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Analog  Tape  Digitizing  System  (ATDS) 

Air  Force  security  regulations  were  reviewed  with  respect  to  their 
implementation  on  the  ATDS,  a  Masscomp  computer.  Passwords  were  set  up  for 
the  system  and  single  user  accounts.  System  file  permissions  were  reviewed. 
Files  related  to  the  use  of  6250  6PI  tapes  for  backups  were  recovered  and 
backup  procedures  were  generated  and  documented. 


Laser  Transit  Anemometer  (LTA)  /  Laser  Doppler  Velocimeter  (LDV) 

Battelle  provided  hardware  and  software  maintenance  and  upgrade  support  for 
the  DEC  LTA  and  LDV  systems. 

Requirements 

-  Increase  the  RS232  communication  from  four  to  six  ports  to  include  the 
traverse  table  operation. 

-  Convert  either  the  LTA  software  in  RT11  version  4.0  or  the  Traverse 
Table  software  in  RT11  version  5.0  to  a  common  version  of  software  so 
both  sets  of  programs  can  operate  at  one  time. 

-  Modify  the  LTA  software  so  it  can  access  the  Traverse  Table  software 
from  "front  page"  commands. 

-  Modify  the  LTA  software  to  write  the  reduced  values  of  velocity  and 
turbulence  level  to  the  LTA  file  so  they  can  be  printed. 

-  Modify  the  LTA  software  to  read  an  LTA  file  and  redisplay  the  data. 

-  Develop  a  print/plotter  output  capability  of  the  LTA  or  Traverse  Table 
displays. 

-  Support  the  investigation  and  resolution  of  electronic  problems  that 
arise  in  the  LTA  system. 

-  Purchase  windows  to  transmit  laser  light. 

-  Establish  a  working  LDV  MicroVax  computer  system  with  needed  user 
accounts. 

-  Install  NASA  LDV  software  on  LDV  MicroVax. 

-  Implement  LDV  computer  control  of  TSI  Frequency  Shifters. 

-  Implement  LDV  computer  control  of  Traverse  Table,  transferring  control 
code  from  PDP-11  if  possible. 

-  Incorporate  Frequency  Shifter  and  Traverse  Table  control  into  NASA 
LDV  software. 
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-  Install  NASA  LTA  software  on  LDV  MicroVax. 

-  Provide  general  LOV  MicroVax  system  support. 

-  Establish  security  procedures  for  LOV  CRF  classified  operations. 


Battelle  Actions  and  Results 

Battel le  performed  the  following  tasks  to  resolve  problems  and  enhance  the  LTA 
and  LDV  systems. 

An  eight  channel  serial  line  Interface  was  purchased  and  Installed  which 
Increased  the  number  or  RS232  communication  ports  from  four  to  six.  This 
interface  also  allowed  for  traverse  table  operation  as  part  of  the  LTA  system 
or  a  stand  alone  job. 

The  LTA  and  the  Traverse  Table  (TRV)  software  were  supported  under  different 
versions  of  the  DEC  RT11  operating  system.  The  LTA  software  executed  under 
DEC  RT11  Version  4.0,  and  the  TRV  software  executed  under  DEC  RT11  Version 
5.0.  Battelle  converted  the  LTA  software  to  run  under  DEC  RT11  Version  5.1  XM 
Monitor  and  linked  it  to  the  virtual  overlays  to  speed  up  software  execution. 

Read/Write  capabilities  for  the  eight-inch  floppy  disk  drive  were  not 
initially  available;  however,  patches  were  obtained  and  installed.  The  TRV 
software  was  brought  up  to  execute  under  the  same  Monitor  to  allow  switching 
between  systems  without  rebooting. 

A  study  was  performed  to  analyze  whether  the  LTA  software  could  be  modified  to 
access  the  Traverse  Table  software  from  front  page  commands.  Many 
problems  associated  with  Integrating  TRV  functionality  Into  the  LTA  software 
were  identified.  The  two  most  significant  problems  were: 

-  LTA  software  was  written  In  Pascal  while  TRV  software  was  written  In 
FORTRAN  and  Macro-11.  Multiple  languages  would  significantly  compound  the 
integration  effort. 

-  Tests  were  performed  to  Interface  the  software  with  the  required  external 
devices.  It  was  found  that  the  Traverse  Table  position  cannot  be  recorded 
on  the  "front  page"  or  "panel"  because  it  attempts  to  move  the  table  and 
will  ultimately  stall  the  software. 

Final  results  Indicated  that  commanding  and  reading  the  SONY  DRO  unit  from  the 
LTA  software  was  possible.  However,  commanding  the  Modulynx  unit  to  move  the 
table  is  neither  a  simple  nor  straight  forward  task.  Minor  integration  of  the 
two  software  systems  was  performed.  The  issue  of  a  major  rewrite  was 
postponed. 
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Modifications  were  made  to  LTA  software  to  write  the  reduced  values  of 
velocity  and  turbulence  level  to  the  LTA  file  to  be  printed.  It  was 
discovered  that  if  a  data  file  was  reviewed  online  during  LTA  testing  the 
values  of  velocity  and  turbulence  level  were  stored  in  the  LTA  file.  However, 
if  the  online  review  is  not  performed,  the  velocity  and  turbulence  level  were 
not  calculated  and  consequently  not  stored  in  the  data  file.  An  acceptable 
solution  was  implemented  to  calculate  the  velocity  and  turbulence  level  for 
each  data  point  as  it  is  taken  and  stored  on  the  LTA  file,  independent  of 
whether  an  online  review  was  done. 

Software  modifications  were  made  so  an  LTA  data  file  could  be  read  into  a 
post-processing  program.  This  functionality  was  not  considered  in  the  initial 
design  of  the  software  and  will  require  additional  Air  Force  in-house  review 
to  resolve  the  discrepancy  between  post-processed  and  online  data.  Battel le 
was  also  asked  to  read  the  data  back  into  the  online  software  routines  so  the 
graphs  could  be  reproduced.  The  post -processing  routine  uses  FORTRAN  and  the 
Air  Force  needs  to  obtain  the  license  and  manuals  for  the  FORTRAN  compiler  for 
the  DEC  equipment. 

A  printer  handler  for  the  Decwriter  II  was  purchased  and  installed. 

Alternative  approaches  for  implementation  of  modifications  to  the  LTA  and  TRV 
were  addressed  in  September  1985,  and  January  1986,  memos  to  the  Air  Force. 
Battel le  obtained  quotations  from  manufacturers  related  to  the  custom 
development  of  five  windows  to  transmit  laser  light.  The  window  specifications 
were  generated  by  the  Air  Force,  and,  upon  their  selection  of  a  manufacturer, 
the  windows  were  purchased  by  Battel le. 

The  Air  Force  then  purchased  an  LDV  MicroVax  computer  system.  The  Vax  VMS 
operating  system  was  installed,  and  user  accounts  established.  The  system 
account  was  protected,  and  standard  'default'  accounts  were  disabled.  The 
printer  was  configured  and  the  necessary  queue  established  on  the  system. 
Captive  accounts  and  procedures  were  developed  to  allow  both  shutdown  of  the 
system,  and  backup  of  the  total  system's  software  by  non-privileged  users, 
without  full  access  to  system  privileges.  This  removes  the  need  for  a 
constant  system  operator,  without  exposing  the  system  to  well-meaning,  but 
unknowledgeable  users  with  system  privileges. 

Support  was  provided  to  NASA  personnel  during  the  initial  installation  of  the 
NASA  LDV  software  in  a  temporary  directory.  After  NASA's  initial  installation 
and  testing,  the  software  was  moved  to  its  own  account  directories.  Directory 
references  within  the  code  were  modified  for  the  LDV  MicroVax  environment. 

The  proper  cabling  for  the  TSI  Frequency  Shifter  control  was  determined  in 
conjunction  with  Air  Force  personnel.  Software  interface  routines  were  then 
created  to  allow  control,  including  status  checking,  of  the  frequency 
shifters.  A  crude,  but  effective  driver  was  written  to  allow  direct  computer 
control  of  the  shifters  by  the  user.  A  minor  hardware  modification  was  made 
to  the  TSI  Frequency  Shifters  to  allow  Local/Remote  operation  status  to  be 
read  by  the  interface  software.  The  status  checking  routines  of  the  software 
interface  were  modified  to  incorporate  this  change. 
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At  the  onset  of  this  task,  It  was  hoped  that  the  control  software  for  the 
Traverse  Table  could  be  transferred  with  little  modification  from  the  PDP-11 
LTA  computer.  After  sorting  through  all  the  available  pieces  of  the  software, 
It  was  determined  that  a  lot  of  It  was  not  actually  used  and  most  of  the 
PDP-11  software  was  written  In  PDP-11  MACRO  language.  It  was  then  decided 
that  It  would  be  more  efficient  to  totally  rewrite  the  Traverse  Table  software 
for  the  MlcroVax.  Since  a  total  rewrite  was  necessary,  the  decision  was  made 
to  use  the  power  of  the  MicroVax  VMS  operating  system  routines  to  write  the 
interfaces  In  the  higher  level  language  FORTRAN.  This  would  allow  easier 
conversion  for  operating  system  or  computer  upgrades,  and  If  rewrite  was 
necessary,  an  easier  understanding  of  the  algorithms  for  the  programmer.  A 
complete  set  of  control  routines  and  documentation  provide  a  simple  Interface 
for  Traverse  Table  control  to  the  user's  code.  Work  was  slowed  on  this  task 
by  the  lack  of  documentation  on  the  Modulynx  controller  Interface,  and  the 
apparent  discrepancies  between  the  documentation  and  the  observed  function  of 
the  equipment.  A  crude,  but  functional  interface  driver  was  written  to  allow 
direct  computer  control  of  the  Traverse  Table  by  the  user. 

A  separate  program  was  written  to  use  the  Traverse  table  Interface  to  seek  an 
'absolute'  origin  provided  by  the  Traverse  Table  Position  Indicator  hardware. 
Testing  of  the  repeatability  of  locating  this  origin  yielded  even  better 
results  than  anticipated.  The  accuracy  and  repeatability  of  table  movement 
was  tested  in  the  mid-axes  range  with  excellent  results.  Testing  at  the 
extremes  of  the  axes  was  impractical  due  to  the  difficulty  of  mounting 
measurement  standards  and  micrometer  dial  indicators,  but  some  preliminary 
tests  alluded  to  results  equalling  those  in  the  mid-axes  range. 

A  new  'working'  version  of  the  NASA  LDV  'tsi_acquire'  data  acquisition 
software  was  created  to  incorporate  the  CRF  Traverse  Table  and  Frequency 
Shifter  control  interfaces.  This  also  Included  the  slight  modification  of 
several  other  program  features  to  better  fit  into  the  CRF  environment. 
Procedures  used  to  compile  and  link  the  software  were  modified  to  Incorporate 
the  interface  code. 

The  NASA  LTA  software  has  been  'installed'  In  Its  own  account  directories. 
Explicit  directory  references  throughout  the  code  were  modified  to  reflect 
local  system  directory  configuration.  The  software  was  reviewed  with 
compressor  test  group  members. 

Battel le  has  functioned  as  an  'open  shop'  to  users  of  the  LDV  MicroVax  system, 
with  training  and  assistance  provided  to  users  on  an  informal  basis  at  both, 
the  system  and  programmer  levels.  Technical  support  was  provided  concerning 
future  system  configuration  and  expansion  needs. 

Specific  problems  on  the  MicroVax  system,  such  as,  sporadic  write-lock  errors 
on  the  system  disk  drive,  were  investigated  by  Battelle.  In  this  case,  the 
EMULEX  controller  diagnostics  were  procured  from  Cambridge  Automation,  and  the 
disk  tested.  This  included  over  18  hours  of  disk  verification;  writing, 
reading,  and  comparing,  sixteen  different  bit-patterns  to  every  sector  of  the 
disk  at  least  twice.  This  process  did  not  reveal  a  single  error.  DEC  service 
personnel  were  unable  to  diagnose  the  problem  due  to  its  sporadic  nature. 
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ENULEX  was  called  directly  for  ideas  on  how  to  isolate  the  problem.  No 
similar  problems  with  the  revision  of  the  controller  board  on  the  LDV  MicroVax 
system  had  been  encountered.  An  upgrade  kit  to  bring  the  controller  board  up 
to  the  latest  revision  was  obtained  by  the  Air  Force  and  no  further  disk 
write- lock  errors  have  been  experienced. 

The  development  of  security  procedures  for  CRF  classified  operations 
encompasses  a  wide  variety  of  tasks,  and  has  taken  a  number  of  approaches.  The 
original  thrust  included  the  use  of  the  existing  disk  drives  on  the  system. 
This  constraint  brought  on  a  number  of  problems  because  all  disks  used  during 
classified  processing  must  be  totally  overwritten  with  several  bit-patterns. 
Toward  this  end,  the  second  disk  drive  on  the  system  was  split  into  two 
'logical'  drives.  This  was  done  by  reprogramming  the  controller  board,  making 
the  operating  system  believe  it  has  three  disks  attached  to  it.  This  was  not 
done  to  increase  the  number  of  drives  on  the  system,  but  to  decrease  the  size 
of  the  disk  used  during  CRF  classified  operations.  The  logical  drive  was 
sized  to  provide  the  needed  space  during  a  run,  but  minimize  the  time  needed 
to  'clear'  the  disk  afterwards.  A  method  was  developed  for  use  in  the 
classified  'shutdown'  to  Insure  that  only  the  proper  disk  was  used  during  the 
CRF  run.  Any  other  disks  used  would  tremendously  increase  the 
declassification  time,  and  would  probably  result  in  lost  software/data. 

A  completely  separate  software  system  was  constructed  for  CRF  classified 
operation,  with  only  the  LDV  and  LTA  user  accounts.  This  was  to  help  decrease 
the  needed  disk  size  and  to  help  prevent  usage  of  unauthorized  disk  drives. 

The  system  is  kept  on  tape  like  a  normal  full-system  backup,  and  is,  itself, 
unclassified.  Any  data  collected  during  CRF  runs  would  be  transferred  to  a 
classified  tape.  The  system  is  not  saved  at  the  end  of  a  run,  but  rebuilt 
from  the  same  tape  for  each  run.  This,  not  only  allows  the  system  tape  to 
remain  unclassified,  but  allows  the  system  to  be  Installed  on  the  disk 
previous  to  creating  a  classified  environment.  Procedures  have  been  written 
to  save  the  data  files  to  tape,  to  backup  the  system  if  software  Is  changed, 
and  to  build  the  system  on  disk.  At  this  point  several  problems  became 
apparent.  The  time  required  to  save  the  collected  data  to  tape,  clear  the 
disks,  and  rebuild  the  operating  system  for  the  next  day,  was  estimated  to  be 
over  two  hours.  This  amount  of  time  after  each  days  operation  seems 
unacceptable.  It  was  also  discovered  that  the  MicroVMS  operating  system  did 
not  allow  writing  physical  blocks  to  disks,  as  the  VMS  operating  system  did. 

At  this  time,  we  had  no  manuals  beyond  the  very  basic  users'  set.  This 
ability  was  necessary  to  Insure  that  each  and  every  sector  of  the  disk  was 
written  over  by  the  required  security  bit  patterns.  The  only  other  way  to 
insure  this,  was  to  write  the  task  at  the  'device  driver'  level,  a  long  and 
difficult  process,  or  to  train  all  personnel  to  run  the  field  service 
diagnostics.  Either  option  is  both  risky  and  time  consuming. 

Battelle  proposed  the  purchase  of  a  removable  Winchester  disk  subsystem  which 
is  the  safest,  most  cost  effective,  as  well  as  the  classical  approach  to  disk 
security  in  classified  operations. 
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These  Winchester  style  drives  can  replace  the  existing  drives  giving  a 
comparable  capacity  (760  Mbytes)  In  a  removable  configuration.  Since  the 
whole  drive  Is  removed  as  a  unit,  the  drives  do  not  suffer  from  the  usual  loss 
of  capacity  and  transfer  rate  seen  In  removable- pack  drives. 

It  was  proposed  that  two  'drives',  one  for  normal  and  one  for  classified 
running,  be  purchased.  At  the  end  of  a  day's  run  the  classified  disk  would  be 
removed  and  locked  In  a  safe,  eliminating  the  time  needed  to  clear  the  disk 
and  rebuild  the  operating  system.  This  should  reduce  the  declassification 
time  to  under  a  half-hour.  When  not  in  a  classified  test  run,  the  second 
drive  would  be  used  for  system  operation.  If  a  drive  should  somehow  be 
destroyed,  there  would  still  be  a  drive  that  could  be  'classified'  and  used  to 
minimize  down-time  during  a  run. 

A  number  of  vendors  were  queried  as  to  available  systems  and  our  findings  were 
given  to  the  Air  Force. 

A  method  to  over-write  physical  memory  with  security  bit  patterns  Is  being 
researched  for  the  LDV  MlcroVax. 


26 


Test  Support  (4.1.2) 


REQUIREMENTS 

This  task  shall  require  the  contractor  personnel  to  assist  the  Air  Force 
during  R&O  testing  in  order  to  acquaint  them  with  the  system,  to  demonstrate 
problems  to  them,  and  in  many  cases  for  them  to  check  out,  debug  or  tune  their 
modifications  online.  This  shall  occasionally  require  up  to  12-hour  workdays 
at  short  notice  and/or  second  or  third  shift  operation. 

BATTELLE  ACTIONS  AND  RESULTS 

CRF  minimum  manning  support  was  provided  for  the  positions  of  IBM  and  Data 
Operator  as  well  as  for  Modcomp  first  floor  signal  conditioning  room. 

Support  was  provided  for  High  Tip  Speed  I,  Fan  Durability,  Laser  Transit 
Anemometer,  F100,and  GE  Swept  Rotor  compressor  classified  and  unclassified 
testing. 

Noload,  12.4,  Frequency  converter  and  Auxiliary  test  runs  were  supported. 
Frequency  converter  maintenance  procedures  were  supported  to  "sync  in"  the 
frequency  converter. 

Pretest  and  post  test  support  was  also  provided. 


Procurement  and  Installation  of  Drive  System  Hardware  and  Required  Equipment 

as  Defined  in  Task  I  (4.1.3) 


REQUIREMENTS 

The  contractor  shall  procure  and  install  all  hardware  and  equipment  that  the 
contractor  defines  in  4. 4. 6. 5. 

BATTELLE  ACTIONS  AND  RESULTS 

Due  to  the  limited  funding  of  Task  I,  this  subtask  was  not  completed  as 
requested  by  the  Air  Force. 


Development  of  an  Acceptance  Test  Procedure  and  Performance  of  the  Agreed  Upon 
Acceptance  Test  of  the  Drive  System  Developed  in  Task  I  (4.1.4) 


REQUIREMENTS 

The  contractor  shall  develop  an  Acceptance  Test  Procedure  (ATP)  to  thoroughly 
test  the  control  system  developed  In  4. 4. 6. 3  to  demonstrate  the  new  control 
system  using  all  hardware  and  equipment  which  has  been  procured  and  Installed 
in  4.1.3.  After  Air  Force  approval  of  the  ATP,  the  contractor  shall  perform 
this  ATP  and  debug  the  control  system,  hardware,  and  equipment  until  the  ATP 
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runs  successfully.  The  contractor  shall  demonstrate  to  the  Air  Force 
successful  execution  of  this  ATP. 

BATTELLE  ACTIONS  AND  RESULTS 

Due  to  the  limited  funding  of  Task  I,  this  subtask  was  not  completed  as 
requested  by  the  Air  Force. 

Analog  Tape  Digitizing  (4.1.5) 


REQUIREMENTS 

The  contractor  shall  develop  an  Integrated  tape  digitizing  system  that  will: 

-  Digitize  up  to  32  analog  channels  from  magnetic  tape  at  a  sustained 
aggregate  rate  of  up  to  400  KHz. 

-  Allow  operator  control  of  the  tape  speed  and  direct,  drive  selection,  IRIG 
code,  and  filter  types  of  the  analog  tape  recorders. 

-  Control  tape  and  data  acquisition  based  on  a  decoded  IRIG  time. 

-  Control  system  calibration. 

-  Manage  data  files  and  output  data  onto  digital  tapes  In  a  format  that  is 
compatible  with  the  CRF  Main  computer's  6250  BPI  tape  drives  and  with  the 
CRF's  Interactive  Signal  Analysis  Package. 

-  Format  the  output  data  tapes  In  accordance  with  the  existing  CRF  Standard 
Format  Tape  Specifications.  Any  deviations  from  the  CRF  Standard  Format 
Tape  Specifications  shall  be  coordinated  in  advance  with  the  Air  Force. 

-  Allow  for  storage  of  system  setup  states. 

The  contractor  shall  provide  to  the  Air  Force  all  manuals  and  documentation 
provided  by  vendors  and  shall  document  any  modifications  or  additions  to 
software  and  hardware  described  In  these  documents. 


BATTELLE  ACTIONS  AND  RESULTS 

Battel le  defined  and  evaluated  three  prototype  systems  to  meet  the  CRF 
digitizing  requirements.  Preston  and  Modcomp  systems  were  evaluated  because 
of  their  availability  In  the  CRF.  A  Masscomp  system  was  also  evaluated.  Based 
on  Battelle's  recommendations,  regarding  the  three  systems,  the  Masscomp 
system  was  selected.  Battel le  purchased  a  Masscomp  MCS-5500  computer  system 
and  a  data  acquisition  software  package  called  IDARS  developed  by  Creare. 
Battel le  then  assembled  and  Integrated  the  digitizing  system  for  the  CRF  to  be 
used  to  digitize  and  analyze  dynamic  test  data.  The  components  were  procured 
and  assembled.  The  software  was  Installed  and  the  system  checked  out. 

Problems  were  encountered  while  Interfacing  the  Datachron  tape  control  unit 
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(an  existing  CRF  instrumentation  component).  The  Datachron  tape  control  unit 
problems  were  Identified  to  the  Air  Force  and  had  been  previously  documented 
by  Creare.  It  was  agreed  that  Air  Force  personnel  would  resolve  these 
problems.  SOW  item  4. 1.5. 1.6  could  not  be  completed  due  to  the  problems 
encountered.  Funds  were  expended  in  an  attempt  to  resolve  the  problems. 

Battel le  delivered  the  system  to  the  Air  Force  on  August  14,  1986.  An  interim 
technical  report,  as  well  as  all  manuals  and  vendor  documentation,  were 
delivered  to  the  Air  Force  in  August  1986. 
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OVERVIEW 


TASK  B  -  SIMULATOR  SUPPORT  (4.2) 


The  CRF  simulator  Is  Intended  to  be  used  to  test  software  and  database 
modifications  and  to  train  facility  operators.  The  simulator  requires  the 
normal  maintenance  that  any  complex  software  requires.  Although  the  software 
that  simulates  the  facility  Is  fairly  stable,  each  new  test  article  that  Is 
Installed  In  the  CRF  requires  custom  software  to  match  Its  configuration  and 
performance  characteristics.  When  facility  equipment  Is  modified,  a 
corresponding  modification  must  be  made  to  the  simulator.  Sometimes,  a 
different  or  more  detailed  simulation  may  be  required  for  a  piece  of 
equipment.  The  PLC  functions  are  simulated;  so  when  the  PLC  relay  circuits  are 
modified,  a  corresponding  change  is  required  In  the  simulators.  This  task 
involves  work  In  simulation,  real-time  programming,  custom  device  handlers, 
communications  and  database  management.  It  also  Involves  training  Air  Force 
personnel  in  the  operation  of  the  simulator. 


REQUIREMENTS 

The  contractor  shall  maintain  and  repair  the  CRF  facility  simulator  software 
to  keep  It  operational  and  current  with  the  CRF  configuration.  The  operation 
of  the  simulator  requires  access  to  the  CRF  computers,  which  depends  on  the 
Air  Force  testing  schedule.  This  shall  sometimes  require  contractor  personnel 
to  work  second  or  third  shifts.  The  contractor  shall  update  the  Simulator 
User's  Manual  as  required  to  keep  it  current  as  a  result  of  the  contractor's 
maintenance  and  repair  work. 


BATTELLE  ACTIONS  AND  RESULTS 

The  number  of  data  acquisition  channels  was  updated  from  540  to  672  on  the 
Simulator  computer. 

The  first  valve  tuning  software  was  written  for  the  control  computers.  Its 
purpose  was  to  obtain  data  required  to  simulate  the  operation  of  the  valves  in 
the  test  article  control  sequence  and  simulated  testing.  Capabilities  were 
included  to  modify  acceleration  coefficients,  scale  factors,  and  position 
factors  associated  with  Inlet,  Discharge,  and  SV/SB  valves. 

• 

Flow  straightener  data  was  received  from  the  test  group  and  installed. 

Critical  channel  assignments  were  updated.  * 

Memory  space  limitations  quickly  became  a  problem  In  the  control  computers  as 
the  symbiont  device  handlers  were  Installed.  To  help  solve  the  problem  PLC1 
and  PLC2  Simulation  handlers  were  combined  Into  one,  and  the  wide  range 
handlers  on  TAC1,  TAC2,  and  FCC2  were  made  more  efficient  through  the  use  of 
the  Modcomp  QSUNQ  routine. 
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The  main  task  in  the  simulator  was  converted  from  a  onemap  to  a  twomap  task  to 
decrease  system  task  switching  time  and  simulation  cycle  time. 

The  operating  system  was  upgraded  from  Rev  D  to  Rev  F.  Errors  were  corrected 
in  timing  system  routines  which  directly  interfaced  with  the  operating  system. 
Facility  software  has  been  very  volatile  over  the  past  three  years.  The 
successful  use  of  the  Simulator  is  tightly  coupled  with  the  facility  software. 
The  volatility  of  the  facility  software  made  it  very  difficult  to  keep  the 
Simulator  up  to  date.  Documentation  procedures  were  nonexistent  at  that  time 
and  word  of  mouth  was  hard  to  follow. 

The  simulator  became  known  as  a  spare  parts  machine.  It  was  used  to  swap  out 
and  test  bad  hardware  by  SRL.  This  resulted  not  only  in  system  down  time  but 
when  the  system  was  once  again  available  it  was  found  that  Simulator 
components  had  been  disconnected  and  not  reinstalled  correctly.  SRL  installed 
2  Uanco  disk  drives  on  the  Simulator  to  support  the  GE  light  probe  system. 
Alignment  problems  were  present  with  existing  and  new  drives  causing  many 
hours  of  down  time. 


Contract  modification  P00009  dated  December  19,  1986,  eliminated  Task  B  due  to 
the  above  mentioned  problems. 


31 


TASK  C  -  COMPLETION  OF  SIMULATOR  (4.3) 


OVERVIEW 

The  CRF  simulator  requires  functions  that  have  not  been  completely 
Implemented.  These  functions  are  described  In  the  simulator  documents  that 
were  made  available  by  the  Air  Force. 


REQUIREMENTS 

-  The  contractor  shall  develop  a  custom  Max  III  compatible  device  handler 
in  the  DAC  computer  to  route  analog  input  data  from  global  common  instead 
of  from  the  actual  Preston  device.  The  Preston  High  Performance  Data 
Acquisition  System  acquires  test  article  performance  data  for  the  DAC 
computer.  This  handler  shall  function  similarly  to  the  analog  input 
handlers  in  the  control  computers. 

-  The  contractor  shall  develop  a  Max  III  compatible  custom  handler  to  the 
DAC  computer  to  route  I/OIS  digital  I/O  and  analog  outputs  through  global 
common,  instead  of  through  the  I/OIS  hardware. 

-  The  simulator  operator  has  the  capability  to  interject  failures  in  the 
simulated  facility.  This  enables  testing  of  the  CRF  software  limit 
checking,  testing  of  recovery  from  abnormal  conditions,  and  training 
operators.  This  capability  has  never  been  tested.  The  contractor  shall 
develop  an  acceptance  test  procedure  (ATP)  to  thoroughly  test  this 
failure  interjection  capability.  After  Air  Force  approval  of  the  ATP, 
the  contractor  shall  perform  this  ATP  and  debug  the  simulator  until  the 
ATP  can  run  successfully.  The  contractor  shall  demonstrate  to  the  Air 
Force  successful  execution  of  this  ATP. 

-  The  CRF  computers  run  under  simulator  or  real  operating  systems.  To 
ensure  that  the  computers  are  all  running  under  their  simulator  systems 
or  all  under  their  real  systems,  a  microprocessor-based  system  was 
designed  to  communicate  with  the  test  operator  and  with  each  computer  as 
it  starts  up  and  does  not  allow  that  computer  to  run  with  the  wrong 
operating  system.  The  system  has  been  installed  but  has  not  been 
integrated.  The  contractor  shall  integrate  the  microprocessor  system  in 
accordance  with  the  simulator  design.  The  contractor  shall  develop  an 
ATP  to  thoroughly  test  the  functions  of  the  microprocessor  system.  After 
Air  Force  approval  of  the  ATP,  the  contractor  shall  perform  this  ATP  and 
debug  the  microprocessor  system  (including  hardware  and  software  in  the 
microprocessor  and  in  the  CRF  computers).  The  contractor  shall 
demonstrate  to  the  Air  Force  successful  execution  of  this  ATP. 
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BATTELLE  ACTIONS  AND  RESULTS 

Battel le  accomplished  the  following  work  under  this  task: 

-  The  DAC  was  updated  to  include  a  simulator  operating  system. 

-  Communication  software  was  installed  in  the  DAC  and  tested. 

-  Microprocessor  software  was  installed  in  all  four  control  machines  and 
tested. 

-  A  symbiont  device  handler  was  written  for  the  Preston  HPDAS  unit. 

-  Failure  software  testing  was  initiated. 

Contract  modification  P00009  dated  December  19,  1986,  eliminated  Task  C. 
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ENHANCEMENT  SUPPORT  TO  FACILITY  AND  SIMULATOR  ON-LINE 
SOFTWARE  AND  HARDWARE  (4.4) 

During  the  first  year  of  the  contract.  Battel le  performed  a  number  of  tasks  in 
support  of  the  facility  and  simulator  on-line  software  and  hardware.  These 
are  described  in  the  subsections  that  follow. 


TASK  D  -  DATA  ACQUISITION  SYSTEM  SUPPORT  (4.4.1) 


OVERVIEW 

The  test  article  data  acquisition  is  controlled  by  the  data  engineer  via  the 
Monitor  and  Main  computers.  Commands  are  sent  from  the  Main  and  Monitor 
computers  to  the  Data  Acquisition  computer  (DAC).  The  DAC  acquires  data  and 
sends  it  through  the  auxiliary  computer  (AUX)  to  the  Main  computer. 

"Hang-ups"  occur  in  some  situations  when  one  of  the  four  computers  gets  out  of 
sequence  due  to  timing  problems  or  improper  error  recovery.  These  "hang-ups" 
need  to  be  resolved. 


REQUIREMENTS 

The  contractor  shall  investigate  the  data  acquisition  "hang-up"  problems  to 
determine  their  causes  and  develop  a  handshaking  protocol  that  will  guide  the 
four  computers  through  the  proper  sequence  to  provide  graceful  error  recovery 
and  to  provide  additional  status  information  to  the  data  engineer. 


BATTELLE  ACTIONS  AND  RESULTS 

An  extensive  analysis  of  the  Data  Acquisition  system  was  performed  by  Battelle 
through  our  participation  in  online  and  offline  CRF  testing.  Software  and 
documentation  were  reviewed  and  results  were  documented  in  an  Interim 
Technical  Report  delivered  to  the  Air  Force  in  November,  1987.  The 
recommendations  were  implemented  under  Task  A,  Support  to  Facilities. 
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TASK  E  -  MONITOR  COMPUTER  OPERATING  SYSTEM  UPGRADE  (4.4.2) 


OVERVIEW 

The  Monitor  computer  required  an  operating  system  upgrade  from  Max  III  to  Max 
IV.  The  Max  IV  OS  required  more  memory  than  that  available  on  the  Monitor 
computer.  There  was  a  need  to  determine  how  much  memory  is  required  for  the 
upgrade.  Numerous  modifications  had  been  made  to  the  Max  III  OS  during  CRF 
construction  integration.  The  Monitor  had  two  custom  device  handlers  that  were 
not  supported  by  Max  IV.  These  handlers,  which  drive  the  Modcomp  to  Modcomp 
serial  communications  and  the  Ramtek  color  graphics,  needed  significant 
modification  to  be  compatible  with  Max  IV.  There  was  also  a  large  amount  of 
Assembler  language  software  that  required  inspection  to  determine  what 
incompatibility  problems  need  correcting. 


REQUIREMENTS 

The  contractor  shall  determine  what  changes  have  been  made  to  the  Max  III 
operating  system  in  the  monitor  computer,  which  ones  can  be  accomplished  in 
the  applications  software,  which  ones  are  not  necessary,  and  which  of  these 
modifications  shall  be  required  to  be  made  to  Max  IV.  The  contractor  shall 
determine  what  changes  to  make  to  applications  software,  job  control  language 
procedures,  system  generation  and  hardware  to  make  them  compatible  with  Max 
IV.  In  addition,  the  contractor  shall  investigate  modifications  that  will  more 
fully  utilize  Max  IV  features  to  increase  system  performance.  This  task  shall 
require  a  very  good  understanding  of  the  Max  III  and  Max  IV  operating  systems. 


BATTELLE  ACTIONS  AND  RESULTS 

Battel le  performed  the  Monitor  operating  system  upgrade  study  and  submitted  an 
interim  technical  report  in  June,  1986.  The  actual  operating  system  upgrade 
was  performed  under  Task  A  Facilities  Support. 

The  study  defined  the  memory  requirements  which  was  purchased  and  installed  by 
the  Air  Force  through  Systems  Research  Laboratory.  Hardware  revisions  at  the 
board  level  were  installed  by  Modcomp.  Operating  system  modifications,  custom 
device  handlers,  disk  restructuring  and  software  modifications  were  documented 
in  the  study. 


TASK  F  -  ON-LINE  DIAGNOSTICS  (4.4.3) 


OVERVIEW 

The  CRF  computer  network  was  designed  to  detect  abnormal  conditions  in  the 
facility  and  the  test  article.  If  an  abnormal  condition  is  detected,  the 
facility  operator  Is  warned  and  the  facility  test  may  be  terminated  in  one  of 
several  ways,  depending  on  the  condition.  Much  time  and  effort  are  often 
consumed  by  facility  personnel  in  determining  the  exact  cause  of  such 
failures.  Better  online  diagnostics  were  needed  to  Improve  personnel 
efficiency. 


REQUIREMENTS 

The  contractor  shall  investigate  all  causes  of  CRF  abnormal  test  termination 
and  determine  what  diagnostics  now  exist  and  develop  diagnostics  in  both  the 
PLC  software  and  the  Modcomp  software  to  more  extensively  evaluate  the 
abnormal  condition  and  inform  the  operator  of  exactly  what  condition 
terminated  the  test. 


BATTELLE  ACTIONS  AND  RESULTS 

The  Task  F  online  diagnostics  study  was  eliminated  from  the  contract  in 
modification  P00009  in  December  1986. 
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TASK  6  -  PLC  SIMULATION  (4.4.4) 


OVERVIEW 

The  PLCs  are  represented  in  the  simulator  by  a  simplified  model  in  order  to 
minimize  computer  time.  Changes  to  the  PLC  logic  require  corresponding,  but 
often  nontrivial,  changes  to  the  simulator.  The  simulator  design  did  not 
allow  for  easy  changes  because  the  PLC  software  was  considered  fixed.  Our 
experience  has  shown  that  PLC  changes  are  made  frequently.  This  task  shall 
develop  a  method  of  simulating  the  PLCs  that  shall  be  easier  to  change. 


REQUIREMENTS 

The  contractor  shall  study  the  method  used  to  simulate  the  PLC  software  and  to 
develop  a  simpler  procedure  for  updating  the  simulator  with  PLC  logic 
modifications.  This  may  require  a  change  in  the  simulation  method  used,  but 
the  performance  of  the  simulator  must  not  be  reduced. 


BATTELLE  ACTIONS  AND  RESULTS 

The  Task  G  PLC  Simulation  study  was  eliminated  from  the  contract  in 
modification  P00009  in  December  1986. 


TASK  H  -  GRAPHICS  RESPONSE  TIME  (4.4.5) 


OVERVIEW 

The  Monitor  computer  displays  facility  data  to  the  test  operators  using  two 
Ramtek  9100  color  graphics  generators  that  drive  four  CRTs  each.  The  time 
between  updates  can  be  quite  long  for  operators  to  monitor  quickly  changing 
variables.  The  update  time  using  one  CRT  is  good,  but  using  additional 
displays  degrades  the  response  time.  Effective  monitoring  of  the  facility 
requires  that  update  time  when  multiple  CRTs  are  used  be  decreased. 


REQUIREMENTS 

The  contractor  shall  investigate  the  cause  of  the  long  update  time  in  the 
color  graphics  system  and  recommend  methods  of  reducing  that  time. 


BATTELLE  ACTIONS  AND  RESULTS 

The  Task  H  graphics  response  time  study  was  performed  in  conjunction  with 
several  tasks  associated  with  this  contract.  Graphics  response  time  was  an 
issue  addressed  in  the  Monitor  operating  system  upgrade  study  and  the  actual 
upgrade.  Throughout  this  study  we  worked  with  facility  personnel  to 
streamline  display  and  alarm  indicator  requirements.  An  interim  technical 
report  was  delivered  in  December  1987. 
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TASK  I  -  Drive  System  Control  Instability  (4.4.6) 

OVERVIEW 

The  frequency  converter  (FC)  is  a  44,000  hp  machine  that  is  driven  by  two 
5,500  hp  DC  motors  to  a  speed  of  514  rpm,  where  the  FC  output  is  equal  to  that 
of  the  synchronous  drive  motor,  which  Is  being  turned  at  10  rpm.  This  is 
required  to  synchronize  the  drive  motor  with  the  frequency  converter.  Once 
synchronized,  the  drive  motor  speed  is  a  function  of  the  FC  speed.  The  problem 
encountered  is  that  the  FC  speed  becomes  unstable  when  it  approaches  500  rpm. 
This  causes  excursions  of  DC  motor  armature  current  at  1000  amps/sec,  which  is 
Intolerable  at  this  high  commutator  speed.  Little  control  is  available  to  the 
digital  control  loop  because  a  small  acceleration  requires  a  large  armature 
current  at  this  speed.  To  get  around  this  problem,  the  DC  motors  do  "push-ups" 
(the  speed  is  repeatedly  ramped  from  100  RPM  to  500  RPM  and  back).  For  unknown 
reasons,  this  reduces  the  instability  enough  to  synchronize  the  drive  motor. 
Three  digital  models  of  the  CRF  electrical  drive  system  were  made  available  to 
the  contractor  for  use  in  this  task.  The  three  models  are  the  Cadre  model,  the 
System  Control  Technology  model,  and  the  Air  Force  Institute  of  Technology 
model . 


REQUIREMENTS 

The  contractor  shall  investigate  the  instability  in  the  CRF  electrical  drive 
speed  control  system  and  determine  all  hardware/software  modifications 
required  for  a  stable  system. 

4. 4. 6. 1.1  The  contractor  shall  develop  a  model  to  predict  the  performance 
of  the  CRF  electrical  drive  system  including  speed  control.  The 
contractor  shall  review  the  three  existing  Air  Force  digital 
models,  selection  and  modifying  parts  of  these  models  as 
applicable  for  use  in  developing  a  new  model. 

4. 4. 6. 1.2  Output  of  the  model  shall  include  input  and  output  parameters 
(volts,  watts,  vars,  torque,  angle,  speed  setpoint,  ramp  rate, 
speed,  pullout  point)  for  each  drive  component.  The  contractor 
shall  design  the  model  to  be  modular  so  individual  components  can 
be  easily  removed,  added,  or  interchanged.  The  input  and  output 
parameters  shall  be  limited  by  the  physical  limits  of  the 
equipment  being  modeled. 

4. 4. 6. 1.3  The  contractor  shall  determine  the  characteristics  and  transfer 
functions  of  each  drive  and  speed  system  component.  Literature 
reviews,  physical  tests,  and  subcontracts  to  original 
manufacturers  or  consultants  may  be  used  for  analysis  and  tests. 

4. 4. 6. 2  The  contractor  shall  develop  an  Acceptance  Test  Procedure  (ATP) 

to  thoroughly  test  the  model  which  was  developed  in  4.4.6. 1.  The 
ATP  shall  demonstrate  the  accuracy  of  the  digital  model  by 
comparing  its  predicted  output  with  the  measured  response  of  the 
electrical  drive  system.  The  results  of  the  comparison  shall  be 
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accurate  within  +10  percent  of  each  model  output  parameter.  A 
comparison  shall  be  made  for  both  steady- state  and  transient 
conditions  for  each  model  output  parameter.  If  accuracies  within 
the  specified  range  are  not  obtainable,  the  contractor  shall 
provide  a  detailed  explanation  for  the  inaccuracies.  After  Air 
Force  approval  of  this  ATP,  the  contractor  shall  perform  this  ATP 
and  debug  the  model  until  the  ATP  can  run  successfully.  The 
contractor  shall  demonstrate  successful  execution  of  this  ATP  to 
the  Air  Force. 

4. 4. 6. 3  The  contractor  shall  develop  a  speed  control  system  using  the 
digital  model  developed  in  4. 4. 6.1.  The  new  speed  control  system 
shall  provide  for  stable  operation  of  the  facility  while 
obtaining  maximum  acceleration  and  deceleration  rates.  These 
rates  shall  be  limited  only  by  the  physical  characteristics  of 
the  electrical  drive  machinery.  The  speed  control  system  shall 
allow  no  more  than  3  percent  of  setpoint  speed  overshoot  in 
response  to  large/ small  step  speed  commands  and  step  load 
changes.  Within  the  limits  of  the  machines,  recovery  time  shall 
not  exceed  6  seconds,  or  one  cycle,  whichever  is  longer. 
Steady-state  speed  stability  and  error  shall  be  +0.1  percent  of 
setpoint  with  up  to  5  percent  load  changes.  The  new  control 
system  shall  provide  for  power  factor  regulation  on  the  drive 
motors  and  field  current  ramping  for  maximum  torque  if  required. 
The  new  control  system  shall  control  field  current  to  provide 
forced  damping  if  possible.  The  new  control  system  shall 
incorporate  all  safety  and  limit  checks  currently  performed  in 
the  existing  speed  control  system. 

4. 4. 6. 4  The  contractor  shall  develop  an  acceptance  test  procedure  to 
thoroughly  test  the  control  system  developed  in  4. 4. 6. 3  against 
the  model  developed  in  4. 4. 6.1  and  against  the  CRF  simulator  to 
demonstrate  the  new  control  system.  After  Air  Force  approval  of 
the  ATP,  the  contractor  shall  perform  this  ATP  and  debug  the 
control  system  until  the  ATP  runs  successfully.  The  contractor 
shall  demonstrate  to  the  Air  Force  successful  execution  of  this 
ATP. 

4. 4. 6. 5  The  contractor  shall  define  all  hardware,  such  as  transducers  and 
tachometers,  required  to  implement  the  new  speed  control  system. 
This  definition  shall  include  detailed  procurement 
specifications. 


BATTELLE  ACTIONS  AND  RESULTS 

In  February  1984,  Battel le  initiated  preliminary  studies  of  the  speed  control 
drive  system  hardware  and  control  algorithms  to  determine  whether  increased 
performance  could  be  expected.  This  effort  Included  developing  a 
simple  mathematical  dynamic  model  of  the  drive  system's  DC  motors  and 
generators  written  in  the  Basic  language.  Because  the  heart  of  the  speed 
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control  system  Is  the  DC  machines  and  their  field  exciters,  the  simplified 
dynamic  model  primarily  Included  representations  of  these  machines.  The 
effects  of  all  AC  machines  and  the  compressor  loads  were  greatly  simplified. 

With  this  model,  various  control  concepts  were  evaluated.  Initial  results 
Indicated  that  significant  Improvements  could  be  expected  from  existing  CRF 
drive  system  rotating  hardware  by  Implementing  alternate  control  algorithms. 

In  order  to  determine  If  the  DC  machine  field  exciters  would  be  fast  enough  to 
accommodate  a  control  system  with  increased  performance,  Battel le  performed 
experimental  transfer  function  analysis.  The  transfer  function  between  the 
Input  command  to  the  field  exciter  and  the  output  of  the  shunt  Isolation 
amplifier  was  measured  using  random,  small  signal  analysis.  Its  dynamic 
response  was  first  order  In  nature  with  a  time  constant  providing  a  break 
frequency  of  20  Hz.  This  result  Indicated  that  the  field  exciters  were  fast 
enough  to  accommodate  a  new  control  system. 

During  this  time,  Battelle  enlisted  the  services  of  Dr.  Welmer  of  The  Ohio 
State  University  Electrical  Engineering  Department.  His  expertise  in  large 
rotating  power  systems  was  utilized  to  Investigate  the  feasibility  of 
increasing  the  apparent  damping  of  the  30,000  Hp.  synchronous  drive  motor. 

This  task  was  Initiated  because  concerns  were  expressed  by  CRF  staff  that 
Increasing  the  performance  of  the  drive  system  could  potentially  cause 
oscillations  on  the  drive  shaft  of  the  synchronous  drive  motor.  Dr.  Welmer's 
results  established  the  feasibility  of  utilizing  field  control  to  Increase  the 
damping  of  the  drive  motor  shaft  and  minimize  or  eliminate  unwanted 
oscillations.  The  findings  of  the  preliminary  study  prompted  the  Compressor 
Research  Facility  to  request  detailed  modeling  and  control  system  analysis  to 
further  Investigate  possible  changes  to  the  variable  speed  drive  system. 

DETAILED  CRF  DRIVE  SYSTEM  MODEL  AND  CONTINUED  CONTROL  SYSTEMS  ANALYSIS. 

Following  the  Government's  November  27,  1984,  request  to  redirect  efforts, 

Task  I  was  modified  to  the  following  subtasks  to  be  performed  by  Battelle. 

1)  Review  three  existing  speed  control  models  (AFIT,  SCT,  and  CADRE). 

2)  Develop  a  complete  drive  system  model  of  all  hardware  and  implement  on  a 
microcomputer. 

3)  Design  a  new  control  system  for  CRF  drive  system. 

The  results  from  each  of  these  subtasks  are  summarized  below. 

Existing  Model  Review  -  In  preparation  for  developing  and  Implementing  an 
extensive  model  of  the  drive  system,  Battelle  reviewed  three  existing  models. 
During  this  effort  Dr.  Weimer  provided  additional  expertise  for  the  review  of 
the  AC  machinery  model  representations.  Battelle  used  several  components  of 
both  the  SCT  and  the  CADRE  models  In  the  development  of  the  new  dynamic  model. 
The  SCT  model  provided  valuable  parameter  identification  information  for  the 
DC  machinery  models  as  well  as  accurate  representations  of  the  field  exciters. 
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The  CADRE  model  provided  additional  information  used  in  the  development  of  the 
12,400  hp  synchronous  motor  model  as  well  as  the  combined  IFC/30,000  hp 
synchronous  motor  model.  No  portions  of  the  AFIT  model  were  used  because  the 
model  review  Indicated  the  SCT  and  CADRE  models  contained  more  complete 
Information. 

Complete  Drive  System  Model  -  Initial  efforts  in  this  subtask  focused  upon 
identifying  an  appropriate  microcomputer  work  station  and  software.  The 
selected  system  must  perform  as  an  efficient  development  tool  for  the  drive 
system  model  development  and  the  drive  system  speed  control  development.  In 
addition,  it  must  perform  as  a  durable  and  efficient  interface  tool  between 
model  users  and  the  model  itself.  With  these  considerations  in  mind  an  IBM  PC 
based  microcomputer  system  was  specified,  purchased,  and  delivered  to  the  Air 
Force. 

The  simulation  language  chosen  for  implementing  the  drive  system  model  was  the 
Advanced  Continuous  Simulation  Language  (ACSL).  ACSL  follows  the  standards 
established  by  the  Simulation  Councils'  CSSL  Technical  committee  in  1967. 

ACSL  has  full  FORTRAN  compatibility  and  unlimited  program  size.  The  use  of 
ACSL  as  the  drive  system  simulation  language  offers  the  advantages  of  direct 
representation  of  system  component  models  and  extensive  interactive  data 
output  formats.  The  actual  control  algorithms  are  written  in  FORTRAN  and 
incorporated  within  the  ACSL  model.  Therefore,  the  control  code  exercised  by 
the  ACSL  model  simulation  will  be  identical  to  that  used  on  the  CRF  drive 
control  computer.  The  use  of  ACSL  resulted  in  a  very  flexible  and  easy  to  use 
drive  simulation  work  station  for  both  the  developer  of  the  model  and  the  end 
user. 

The  actual  mathematical,  dynamic  model  of  the  drive  system  includes 
representations  of  the  following  hardware: 

1)  Both  AC  and  DC  field  exciters  including  voltage  and  current  limitations. 

2)  12,400  hp  synchronous  motor. 

3)  DC  motors  and  generators. 

4)  Induction  Frequency  Converter  (IFC). 

5)  30,000  hp  synchronous  drive  motor. 

6)  Gearbox  and  compressor  loads. 

A  full  model  description  is  provided  in  the  document  titled  "Drive  System 
Dynamic  Model  Documentation,"  dated  February  13,  1987.  Also  included  is  a 
user's  manual,  programmer's  manual,  and  technical  reference  manual. 

In  preparation  for  acceptance  of  the  model  by  the  Air  Force,  Battel le,  in 
conjunction  with  CRF  staff,  prepared  an  Acceptance  Test  Procedure  (ATP)  and 
submitted  it  for  approval  on  July  24,  1986.  The  ATP  Included  comparing  the 
Battelle  developed  model  to  actual  data  from  historical  data  tapes  of  previous 
CRF  compressor  tests.  A  total  of  32  variables  were  compared  to  actual  data 
for  three  constant -speed  tests  and  four  transient  conditions.  Approximately 
95  percent  of  all  data  matched  within  the  required  10  percent  of  full-scale 
output.  Those  values  that  did  not  match  were  attributed  to  transducer 
calibration  error  or  graphical  scaling  errors. 
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The  actual  hardware,  the  fully  functional  model,  and  all  supporting 
documentation  was  delivered  to  the  CRF  on  February  13,  1987. 


Control  System  Design  -  The  first  step  In  the  control  system  design  involved 
performing  a  perturbation  analysis  of  the  DC  machinery.  Such  an  analysis 
provides  valuable  insight  Into  how  the  system  dynamics  change  depending  on  the 
value  of  the  steady  state  operating  conditions.  Results  of  the  analysis 
provided  theoretical  representations  of  the  open  loop  transfer  function 
between  the  field  commands  to  the  DC  generator  and  motor  fields  and  the 
rotational  speed  of  DC  motor  shaft.  This  information  Is  necessary  for 
selecting  appropriate  controller  functions  that  will  provide  consistent 
dynamic  performance  at  all  operating  conditions. 

The  present  CADRE  control  code  was  examined  in  detail  and  all  safety  features 
were  identified  so  they  could  be  incorporated  within  the  new  control  code. 
Limited  funding  prevented  further  development  of  the  new  control  codes. 
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Task  J  -  Software  Configuration  Maintenance  Support  System  (4.5) 


OVERVIEW 

The  Branch  computer  facilities  involve  a  large  amount  of  software  with 
extensive  real-time  interactions  between  computers  and  modules.  The 
maintenance  of  these  systems  is  obviously  a  very  complex  job.  The  Software 
Configuration  Maintenance  Support  System  (SCMSS)  was  developed  to  solve 
this  problem  by  providing  interactive  access  to  an  Intel  System  2000  (S2K) 
database  that  contains  information  on  each  module  and  its  interactions  with 
other  modules.  The  access  requires  the  user  to  use  S2K  commands  and  to  know 
how  the  data  is  stored  in  the  database.  This  requires  specialized  S2K 
expertise,  which  is  not  always  readily  available.  Improvements  are  needed  to 
the  SCMSS  to  simplify  maintenance  due  to  software  changes,  simplify  the  data 
access  methods,  and  expand  the  database's  information. 


REQUIREMENTS 

The  contractor  shall  study  the  SCMSS  and  recommend  improvements  and 
alternatives  to  increase  the  productivity  of  the  system,  to  make  the  system 
easier  to  maintain,  to  simplify  its  use,  and  to  add  more  database  Information. 
The  study  shall  include,  but  not  be  limited  to,  the  following: 

-  Review  of  previously  documented  improvement  possibilities, 

-  Review  of  the  schema  definition, 

-  Consideration  of  S2K  system  software  enhancements, 

-  Inclusion  of  module  comment  and  source  code  line  counts, 

-  Inclusion  of  database  file  structure  usage, 

-  Simplified  update  procedures  to  allow  the  SCMSS  to  keep  pace  with 
software  changes, 

-  Maintenance  of  a  production  software  library  for  all  CRF  test  software  on 
the  Main  computer. 

The  study  and  its  recommendations  will  be  reviewed  for  approval  by  the  Air 
Force.  After  Air  Force  approval,  the  contractor  shall  implement  the 
recommendations. 


BATTELLE  ACTIONS  AND  RESULTS 

Battel le's  study  of  the  CRF  SCMSS  system  included  the  following: 

-  An  evaluation  of  the  combination  of  IBM  and  Modcomp  prescanners. 

-  A  collection  of  information  on  the  automation  of  obtaining  Modcomp  input 
data. 

-  A  study  of  the  methods  used  by  the  prescanners  to  obtain  Information 
from  software  headers. 

-  An  evaluation  of  System  2000  PLEX  database  commands. 
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Upon  completion  of  the  study,  Battel le's  recommendations  were  submitted  to  the 
Air  Force  in  July, 1984.  The  modifications  which  were  implemented  include: 

-  Development  of  one  prescanner  (IBM  and  Modcomp). 

-  Modification  of  the  prescanner  Input  file  to  accept  the  same  format 
input  from  the  IBM  and  Modcomps. 

-  Modification  of  the  IBM  prescanner  to  allow  for  assembler  code  nested  in 
Modcomp  FORTRAN  inline. 

-  Modification  of  the  scanner  to  accept  a  more  flexible  header  format  and 
to  gather  additional  data  during  the  scanning. 

-  Modification  of  string  definitions  to  optimize  searching  the  database. 

-  Review  of  schema  definitions. 

-  Modification  of  FORTRAN  and  Assembler  scanners. 

-  Incorporation  of  SCMSS  and  Simulator  software  into  the  system. 

-  Development  of  a  Plex  load  procedure  and  additional  reporting 
capabilities. 


Contract  modification  P00009  dated  December  19,  1986,  eliminated  additional 
work  on  Task  J. 
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TASK  K  -  MAIN  COMPUTER  SUPPORT  (4.6) 

The  original  contractual  requirement  for  this  task  was  to  provide  operating 
system  and  application  software  support.  Contract  modification  P00001,  dated 
May,  1985,  removed  the  operating  system  support  requirement. 


OVERVIEW 

The  Main  computer  is  an  IBM  4341  computer  used  during  CRF  testing  for  test 
article  data  reduction,  storage,  and  display.  During  periods,  the  Main 
computer  is  used  for  software  development,  database  applications,  engineering 
simulations  and  analysis,  and  post  test  data  reduction.  Improvements  and 
modifications  were  needed  to  the  online  CRF  test  software.  In  addition, 
test-related  software  needed  to  be  developed,  improved,  or  modified  to  enhance 
the  computer's  capabilities  for  support  of  post  test  analysis.  Finally,  S2K 
database  applications  needed  to  be  developed,  maintained,  and  improved. 


Develop,  Support,  and  Enhance  S2K  Database  Applications  (4.6.1) 


REQUIREMENTS 

The  contractor  shall  develop,  support,  and  enhance  S2K  database  applications. 
The  contractor  shall  also  maintain  and  update  the.  S2K  system  software  and 
associated  documentation,  as  required,  based  on  periodic  changes  issued  by  the 
software  supplier.  Specific  database  applications  that  are  required  are  a 
tape  library  database,  a  manuals  database,  a  static  data  point  database,  and  a 
Main  computer  usage  accounting  database.  The  contractor  shall  review  the  S2K 
Control/2000  option  for  possible  use  by  these  or  other  databases. 


BATTELLE  ACTIONS  AND  RESULTS 

Battelle  installed  S2K  release  11.0  single  user  mode  on  the  IBM  MVT  system. 

The  multi-user  mode  was  being  installed  when  the  IBM  operating  system  was 
upgraded  from  MVT  to  MVS.  S2K  was  later  installed  on  the  MVS  system. 

Two  Cobol  report  applications  were  converted  to  S2K  Report  Writer  to  delete 
the  requirement  for  the  Cobol  compiler.  Documentation  was  updated  and 
the  IBM  operator  was  trained.  Backup  procedures  were  generated. 

When  S2K  release  11.5  was  installed,  the  tape  and  manuals  databases  were 
streamlined  to  remove  erroneous  and  duplicated  data.  String  functions  were 
updated  to  remove  unnecessary  null  entries  and  new  strings  were  added  to  allow 
the  operator  to  more  efficiently  accomplish  database  updates.  The  eight  disk 
database  files  associated  with  each  database  were  modified  In  size  for  more 
efficient  data  storage. 
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Predefined  access  methods  for  the  tape  library  and  manuals  databases  were 
eliminated.  Batch  access  methods  are  now  being  used  because  they  are  faster, 
more  user  friendly  and  flexible. 


Tape  Library  Database  (4. 6. 1.1) 


REQUIREMENTS 

For  the  tape  library  database,  the  contractor  shall  study  the  current  tape 
library  documents  and  tape  certification/recertification  process  and  develop 
recommendations  for  a  database. 


BATTELLE  ACTIONS  AND  RESULTS 

Battel le  studied  tape  library  documents  and  the  tape  certification/ 
recertification  processes  tc  develop  a  design  for  the  CRF  tape  library 
database.  Battelle  designed  the  original  schema  and  Installed  the  first 
version  of  the  tape  library  database  (S2K  release  2.9).  Additional 
modifications  were  recommended  In  June,  1984.  These  modifications  were 
approved  by  the  Air  Force  and  Implemented. 

Command  strings  were  generated  and  Incorporated  Into  the  database  to 
facilitate  update,  query  and  reporting  functions.  A  command  was  created  to 
give  the  user  Interactive  access  to  the  database.  User  notes  and  system 
documentation  were  generated.  Battelle  Installed  S2K  Release  11.0  in  early, 
1986,  and  converted  the  tape  library  database  files  to  work  with  the  new 
release.  In  May,  1986,  upon  conversion  to  the  MVS  operating  system,  Battelle 
added  additional  string  functions  to  Incorporate  additional  S2K  Release  11.5 
features,  obtain  additional  Information  from  the  database  and  make  the 
database  maintenance  duties  easier.  S2K  Report  Writers  were  developed  to 
create  reports  thus  helping  to  eliminate  the  requirement  for  a  Cobol  compiler 
In  the  CRF. 

Open  shop  consultation  on  S2K  was  provided  throughout  the  contract  period. 


Manuals  Database  (4. 6. 1.2) 


REQUIREMENTS 

The  present  manuals  database  shall  be  maintained  by  the  contractor. 
Enhancements  are  required  to  add  data  fields  to  ease  locating  specific 
documents  and  to  Incorporate  more  document  types. 
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BATTELLE  ACTIONS  AND  RESULTS 


Battelle's  proposed  enhancements  to  the  Manuals  database  (S2K  release  2.9)  in 
June  1984,  were  approved  by  the  Air  Force. 

Command  strings  were  generated  and  incorporated  into  the  database  to 
facilitate  update,  query  and  reporting  functions.  A  command  was  created  to 
give  the  user  interactive  access  to  the  database.  User  notes  and  system 
documentation  were  generated.  Battel le  installed  S2K  Release  11.0  in  early 
1986  and  converted  the  Manuals  database  files  to  work  with  the  new  release. 

In  May,  1986,  upon  conversion  to  the  MVS  operating  system,  Battelle  added 
additional  string  functions  to  incorporate  S2K  Release  11.5  features,  obtain 
additional  information  from  the  Manuals  database  and  make  the  database 
maintenance  duties  easier.  S2K  Report  Writers  were  developed  to  produce 
reports,  thus  helping  to  eliminate  the  requirement  for  an  IBM  Cobol  compiler 
in  the  CRF. 

Open  shop  consultation  on  S2K  was  provided  throughout  the  contract  period. 


Static  Data  Point  Database  (4. 6. 1.3) 


REQUIREMENTS 

A  database  is  needed  of  all  static  data  points  acquired  during  CRF  testing. 

The  contractor  shall  study  the  present  data  acquisition,  storage,  and 
retrieval  process  along  with  anticipated  post  test  data  analysis  needs.  Based 
on  the  study  results,  the  contractor  shall  recommend  a  database  to  meet  the 
analysis  needs. 

BATTELLE  ACTIONS  AND  RESULTS 

The  Air  Force  decided  not  to  implement  this  database  system,  therefore,  the 
study  was  canceled. 


Main  Computer  Usage  Accounting  Database  (4.6. 1.4) 


REQUIREMENTS 

The  contractor  shall  study  a  partially  completed  database  for  Main  computer 
usage  accounting.  The  contractor  shall  determine  the  present  status  of  the 
database  and  shall  provide  recommendations  on  changes  needed  to  make  the 
database  operational. 

BATTELLE  ACTIONS  AND  RESULTS 

The  Air  Force  decided  not  to  implement  this  database  system,  therefore  the 
study  was  canceled. 
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Provide  for  Transient  Data  Acquisition  (4. 6. 1.5) 


REQUIREMENTS 

The  contractor  shall  make  enhancements  to  the  CRF  Main  computer  online 
software  to  provide  for  transient  data  acquisition.  The  goal  for  transient 
data  acquisition  is  to  acquire  scans  of  150  channels  of  data  at  a  rate  of  400 
scans  per  second  for  one  minute  periods.  The  data  for  each  shall  be  acquired 
from  the  Auxiliary  computer  data  link  and  stored  on  magnetic  disk  and  on 
magnetic  tape.  Modifications  are  expected  to  be  needed  in  the  data  link,  disk 
storage,  and  retrieval,  and  tape  storage  and  retrieval  software.  The 
contractor  shall  study  the  problem  and  make  recommendations.  The  results 
shall  be  provided  to  the  Air  Force  for  approval  prior  to  implementation. 

After  Air  Force  approval,  the  contractor  shall  implement  the  recommendations. 


BATTELLE  ACTIONS  AND  RESULTS 

The  implementation  of  the  transient  data  acquisition  system  incorporated 
changes  in  all  data  acquisition  computers.  This  task  is  documented  under 
Task  A. 


Statistical  and  Signal  Analysis  System  (4. 6. 1.6) 


REQUIREMENTS 

The  contractor  shall  procure  and  install  a  statistical  and  signal  analysis 
system  that  will  operate  on  the  CRF  Main  computer  under  its  MVS  operating 
system  and  will  perform  the  following  data  analysis  functions:  power  spectral 
density,  auto-correlation,  cross-correlation,  cross-spectrum  magnitude  and 
phase,  coherence,  and  transfer.  The  system  shall  provide  data  manipulation  to 
perform  digital  filtering,  data  windowing,  data  sampling,  and  data  detrending. 


BATTELLE  ACTIONS  AND  RESULTS 

Battelle  studied  several  statistical  analysis  packages  which  were  capable  of 
fulfilling  the  requirements  of  this  task.  Upon  completion  of  the  study 
Battelle  recommended  SAS  statistical  software  to  meet  the  CRF  needs.  Upon  Air 
Force  approval  Battelle  purchased  SAS  software  for  installation  on  the  IBM 
Main  computer. 

Systems  and  Applied  Sciences  Corporation  is  under  contract  with  the  CRF  to 
provide  Main  computer  systems  support.  They  have  been  given  responsibility 
for  the  installation  of  the  SAS  software  specified  and  purchased  by  Battelle. 
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Maintain,  Enhance  and  Develop  Software  for  the  Main  Computer  Needed  to  Support 
the  Online  CRF  Data  Acquisition  System  (4.6.2) 


REQUIREMENTS 

The  contractor  shall  maintain,  enhance,  and  develop  software  for  the  Main 
computer  needed  to  support  the  online  CRF  data  acquisition  system.  Software 
shall  be  documented  and  written  In  accordance  with  existing  CRF  standards. 
The  following  list  Identifies  some  of  the  modifications  needed.  For  all  of 
these,  the  contractor  shall  study  the  problem,  the  software,  and  the 
documentation  to  develop  change  recommendations. 


BATTELLE  ACTIONS  AND  RESULTS 
Multi-tasking 

Battelle  was  asked  to  rewrite  the  multi-tasking  software. 

The  Main  computer  system  Is  responsible  for  receiving,  processing,  storing, 
and  displaying  test  article  data  acquired  from  the  various  computers  in  the 
CRF  system.  The  test  article  data  is  gathered  by  the  Data  Acquisition 
Computer  which  passes  it  to  the  Auxiliary  Computer,  which  sends  the  data  to 
the  Main  computer.  All  of  the  data  coming  from  the  DAC  cannot  be  processed  in 
real  time  on  the  IBM.  However,  all  the  data  is  stored  on  magnetic  tape  for 
analysis  and  display  at  a  later  time.  The  software  executing  during 
compressor  testing  is  a  multi-tasking  system  that: 

-  Downloads  database  Information  to  the  Modcomp  computers. 

-  Allows  the  engineers  to  make  database  changes  online  during  testing. 

-  Stores  the  database  and  database  changes  made  during  the  test  on  magnetic 
tape  to  facilitate  post-processing. 

-  Keeps  a  directory  of  all  the  data  files  stored  on  tape  during  a  test. 

-  Allows  the  engineers  to  start  channel  check  and  pressure  calibration 
software,  process  the  data  as  it  comes  from  the  AUX  computer  and  display 
the  results. 

-  Accepts  raw  data  from  the  AUX  computer  and  stores  it  all  on  magnetic  tape 
for  future  playback  and  analysis. 

-  Allows  the  engineers  to  choose  any  display  format  they  wish  to  see  during 
a  test,  and  lets  them  change  displays  rapidly  as  the  need  arises. 

-  Allows  the  engineers  to  make  a  hardcopy  of  their  displays  at  any  time 
during  a  test. 


-  Processes  enough  data  In  real  time  to  allow  an  update  rate  of 
approximately  every  three  seconds  on  the  engineer's  displays. 

-  Handshakes  with  the  AUX  and  Monitor  computers  so  that  the  engineers  are 
aware  of  the  data  acquisition  system's  status. 

After  a  test,  the  Main  Is  the  primary  focus  for  post -processing  and  analysis 
of  data  collected  during  a  test. 

Battelle,  with  Air  Force  Inputs,  designed  multi-tasking  facilities  to 
support  the  new  design  of  the  online  software.  These  facilities  Included 
software  to  attach  and  detach  tasks  from  other  tasks  as  well  as  facilities  to 
allow  these  tasks  to  wait  on  each  other  and  events  occurring  In  the  system, 
post  each  other  to  notify  tasks  when  events  occurred,  and  pass  needed 
Information  from  task  to  task.  Upon  completion  of  the  design  and  development 
of  these  facilities,  a  major  redesign  of  all  online  and  post-processing 
software  was  performed.  Battelle  rewrote  three  large,  complex  IBM  Assembler 
tasks  using  software  engineering  techniques  to  structure  the  software. 

FORTRAN  was  primarily  used  with  Assembler  code  being  used  for  speed.  The 
three  tasks  which  Battelle  rewrote  included  data  link  software,  disk 
storage  and  retrieval  software,  and  tape  storage  software.  All  tasks 
described  below  were  written  to  facilitate  future  modifications  and 
enhancements.  The  internal  documentation  is  very  clear  and  complete. 

The  old  data  link  software  was  written  entirely  in  IBM  Assembler  as  a  single 
3000  line  module.  Its  function  was  to  read  and  write  to  both  the  Monitor  and 
AUX  data  links.  Battelle  broke  this  task  up  Into  six  tasks,  with  a  separate 
task  to  handle  each  link.  Assembler  code  was  only  used  to  handle  the  I/O. 
FORTRAN  code  was  used  for  the  protocol  and  logic.  This  software  Is  now  easier 
to  understand  and  maintain.  The  old  disk  storage  and  retrieval  software  was 
written  in  IBM  Assembler  and  was  not  broken  up  into  separate,  functionally 
strong  subroutines.  This  software  was  the  known  source  of  many  problems  in 
the  online  software.  Battelle  separated  data  storage  and  retrieval  into  three 
separate  tasks.  One  task  responds  to  any  task  In  the  online  system  which 
needs  to  read  or  write  a  database  record.  Another  task  is  then  directed  to 
perform  the  actual  I/O  and  return  the  needed  information  to  the  calling  task 
if  the  request  was  a  read  operation.  Another  task  reads  and  writes  raw  data 
from  the  AUX  computer  when  the  tape  storage  task  is  too  busy.  The  I/O  is 
redirected  to  disk  when  it  is  detected  that  the  tape  storage  software  is  busy, 
which  is  usually  the  case  when  tape  storage  has  filled  up  one  tape  and  is  in 
the  process  of  mounting  another. 

Battelle  broke  the  tape  storage  software  up  Into  four  tasks.  Two  FORTRAN 
tasks  control  the  logic  to  wait  on  other  tasks  and  format  the  data  to  be 
written  to  tape  and  the  tape  directory.  Two  assembler  tasks  were  created  to 
write  the  data  to  tape  and  the  tape  directory. 

The  old  data  acquisition  software  used  a  buffering  scheme  In  which  data  came 
from  the  link  and  was  buffered  to  a  disk  file.  As  new  buffers  were  written  to 
disk,  the  oldest  buffers  would  be  read  from  disk  and  sent  to  tape  storage. 

This  detour  of  the  data  to  disk  before  being  written  to  tape  was  eliminated  in 
the  new  software  design.  The  new  buffering  scheme  allocates  20  buffers  to  two 
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queues,  the  data  link  queue  and  the  tape  storage  queue.  One  task  reads  data 
Into  the  buffers  In  the  data  link  queue,  and  another  task  moves  the  data  from 
a  buffer  In  the  data  link  queue  to  a  buffer  In  the  tape  storage  queue  and 
alerts  the  tape  storage  task  to  write  the  buffer  to  tape.  If  one  tape  has 
been  filled  and  the  tape  storage  software  Is  waiting  for  the  operator  to  mount 
a  new  one,  the  buffers  In  the  data  link  queue  will  be  written  to  disk 
temporarily.  When  tape  storage  Is  ready  to  receive  data  again,  the  data  will 
be  read  from  disk  Into  the  tape  storage  queue  buffers,  and  tape  storage  will 
be  notified  to  write  the  data  to  tape. 

The  fact  that  the  data  Is  not  written  to  disk  and  read  back  from  disk  before 
It  Is  written  to  tape  helped  to  speed  up  the  software.  This  helped  the  Main 
software  to  be  fast  enough  to  handle  transient  data  (discussed  In  Task  A). 


Task  Communications 

The  task  communication  routines  used  by  the  multi-tasking  run-time  software 
were  developed  by  Battelle  In  conjunction  with  the  Air  Force.  These  routines 
allow  tasks  to  pass  information  to  one  another  so  that  critical  timed  event 
sequences  within  the  software  are  properly  started,  coordinated,  scheduled, 
and  stopped.  Five  tasks  were  developed  to  perform  the  following  functions: 

-  Place  a  task  on  the  ready  queue, 

-  Take  a  task  out  of  the  ready  queue, 

-  Allow  a  task  to  wait  on  an  event  or  events, 

-  Allow  a  task  to  notify  a  waiting  task  that  an  event  has  happened, 

-  Allow  a  task  to  retrieve  information  from  another  task. 

These  routines  were  incorporated  Into  all  Main  run-time  and  post-processing 
software. 

Reduction  Software 

Battelle  implemented  changes  to  the  reduction  software  to  correct  floating 
point  to  fixed  data  conversion  problems.  Software  changes  were  made  to  check 
the  performance  constants  the  data  operator  can  set  to  see  whether  performance 
and/or  statistical  software  should  be  executed.  Changes  were  made  to  the  EUC 
routines  to  convert  degrees  F  to  degrees  R.  The  reduction  software  was 
modified  to  handle  abort  data. 

The  reduction  task  initializes  several  common  blocks  when  it  is  attached. 

Some  of  the  information  in  these  common  blocks,  such  as,  performance 
constants,  can  be  changed  by  the  data  operator  during  a  run.  This  would  mean 
that  the  Information  in  the  common  blocks  would  become  outdated  as  the  run 
progressed.  In  the  old  design  the  reduction  software  would  be  stopped  and 
restarted  when  Information  in  these  common  blocks  was  affected.  Battelle 
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rewrote  the  software  so  that  it  could  be  notified  of  the  change  and  branch 
back  to  Its  Initialization  code  when  needed.  This  eliminated  the  need  to  stop 
and  restart  the  reduction  software  during  a  run,  which  saves  time. 


Miscellaneous  Support 

The  master  control  task  was  one  large  assembler  routine.  Battelle  broke  it  up  * 

into  20  small  FORTRAN  subroutines  to  make  the  software  more  maintainable. 

When  taking  data  during  a  run,  each  file  which  is  written  to  tape  has  an 
associated  entry  in  the  tape  directory  which  is  kept  on  disk.  When  these  run 
time  tapes  are  merged,  some  of  the  Information,  like  tape  numbers,  must  be 
changed.  Battelle  designed,  wrote,  and  tested  the  tape  directory  maintenance 
program  to  satisfy  this  need.  With  this  program  a  user  can  change,  add  new  or 
delete  old  entries.  Battelle  also  wrote  a  program  to  print  the  tape 
directory. 

Battelle  totally  rewrote  the  B2X  and  X2B  utility  routines.  B2X  changes  an 
Integer  number  into  an  EBCDIC  character  representation,  while  X2B  does  the 
reverse  of  this  operation. 

A  watchdog  task  was  added  to  automatically  check  the  CRT  and  reduction  tasks. 

If  a  task  should  fail,  this  watchdog  task  will  Instruct  the  master  control 
program  to  stop  and  restart  it. 

IBM  Share  routines  were  installed  on  the  IBM  MVT  system. 

Battelle  modified  Mach  number  correction  software. 

Battelle  modified  the  software  which  sorts  through  the  tape  directory  data  to 
display  information  to  a  user.  Several  errors  were  found  and  corrected  in  the 
build  directory  software  which  is  executed  from  any  of  the  CRT  tasks.  It  was 
also  found  that  the  tape  storage  software  was  making  Incorrect  entries  in  the 
tape  directory.  These  problems  were  corrected.  Battelle  rewrote  the  tape 
storage  software  and  broke  out  the  directory  logic  into  separate  tasks. 

Battelle  was  asked  to  keep  the  Main  software  libraries  In  order.  This 

responsibility  included  adding  newly  developed  and  modified  routines  to  the 

proper  libraries,  making  backups  before  and  after  any  library  changes, 

generating  cross-reference  lists  of  which  tasks  use  what  subroutines,  making 

sure  that  any  subroutines  that  were  modified  were  tested  with  all  tasks  in  r 

which  they  are  used,  updating  the  JCL  to  compile  and  link  the  software  as 

required,  keeping  a  current  set  of  listings,  and  generating  a  sequential 

dataset  of  all  Main  run-time  software.  • 

Battelle  added  a  new  help  screen  to  the  CRT  tasks  to  Instruct  the  user  about 
the  new  commands  that  have  been  added. 

Battelle  continually  conducted  open  shop  consultation  for  members  of  the  Data 
Acquisition  Group  and  other  new  personnel  (government  or  contractor)  working 
in  the  CRF. 
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Battel le  supported  the  first  GESRO  channel  checks  to  help  the  engineers  with 
the  new  software. 

Changes  were  made  to  subroutine  SPT1TL  of  the  print  software  to  put  titles  on 
post -processing  static  printouts. 


r 

Set  Configuration  Code  Reading  Number  (4.6.2. 1) 


REQUIREMENTS 

The  Data  Engineer  needs  the  capability  to  set  the  configuration  codes  reading 
number  from  the  Main  computer  alphanumeric  terminal. 


BATTELLE  ACTIONS  AND  RESULTS 

Battel le's  study  Into  the  above  requirement  revealed  that  resetting  of  the 
configuration  code  reading  number  Is  best  performed  at  the  DAC.  Battelle 
modified  the  online  software  In  the  DAC  computer  to  display  a  menu  that  gives 
the  DAC  operator  the  opportunity  to  reset  the  compressor  configuration  code 
reading  number,  channel  check  number  and  pressure  calibration  number  to  zero. 


Database  Parameter  Display  (4. 6. 2. 2) 


REQUIREMENTS 

Several  modifications  are  needed  to  the  Main  computer  alphanumeric  terminal 
software  to  display  more  database  Information,  to  simplify  their  use  and  to 
provide  more  data  to  the  user. 


BATTELLE  ACTIONS  AND  RESULTS 

Battelle  made  program  design  changes  to  modify  the  online  software  so  that  the 
CRTs  could  display  additional  database  Information.  A  problem  was  encountered 
In  that  each  of  the  five  different  types  of  database  file  structures  required 
a  different  display  format.  No  further  steps  were  taken  to  address  the 
problem. 


Tape  Directory  Configuration  Codes  (4. 6. 2. 3) 


REQUIREMENTS 

The  present  online  software  cannot  set  any  of  the  configuration  code  fields  In 
the  Main  Tape  Directory  which  are  calculated  by  the  data  reduction  modules. 
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BATTELLE  ACTIONS  AND  RESULTS 


Battelle  and  the  Air  Force  determined  that  the  Main  online  software  did  not 
need  to  set  the  configuration  codes  since  they  could  be  available  from  the  DAC 
computer.  Battelle  modified  OAC  software  to  send  configuration  code  data  to 
the  Main  computer  In  the  key  area  of  the  ICOUNT  database  file  structure.  The 
Main  computer  Tape  Storage  and  Tape  Directory  software  were  modified  to  read 
the  configuration  code  data  and  put  It  Into  the  tape  directory. 


IBM  Standard  Label  Tapes  (4. 6. 2. 4) 


REQUIREMENTS 

The  test  article  data  tapes  written  by  the  Main  online  software  need  to  have 
IBM  standard  labels  to  simplify  tape  use  and  to  minimize  operation  mount 
errors. 

BATTELLE  ACTIONS  AND  RESULTS 

Battelle  studied  this  requirement  and  determined  that  It  would  not  be  cost  or 
time  effective  to  make  the  required  software  changes  to  use  IBM  standard  label 
tapes.  Standard  IBM  Input/Output  access  methods  were  evaluated  for  use  with 
these  tapes  and  It  was  concluded  that  they  would  be  too  slow  or  require  too 
many  data  definition  cards  In  the  existing  procedures  used  to  execute  the 
online  software. 

Changes  were  made  to  the  Standard  Format  Tape  (SFT)  generation  software  and 
SFT  processing  software  so  that  these  tapes  could  be  created  and  used  with 
standard  IBM  labels. 


Post-Processor  Software  Modifications  (4. 6. 2. 5) 


REQUIREMENTS 

The  Main  computer's  pressure  calibration  and  channel  check  software  need  the 
capability  to  run  from  a  post-processor  tape.  This  will  require  modification 
to  the  online  and  post-processor  software. 


BATTELLE  ACTIONS  AND  RESULTS 

This  subtask  was  accomplished  as  a  by-product  of  the  redesign  and  recoding  of 
the  online  software.  Battelle  Isn't  aware  of  any  problems  which  exist. 
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Simultaneous  Print  Requests  (4. 6. 2. 6) 


REQUIREMENTS 

Simultaneous  print  requests  by  online  terminals  are  not  serviced  properly  by 
the  print  modules.  Conflicts  can  also  occur  if  static  data  points  are  taken 
too  rapidly.  Changes  are  needed  to  resolve  these  problems. 


BATTELLE  ACTIONS  AND  RESULTS 

Battelle  studied  and  accomplished  this  subtask  by  adding  an  I/O  flag  to  the 
intertask  communication  array.  When  any  task  in  the  online  software  wants  to 
perform  FORTRAN  I/O,  it  must  first  test  and  set  the  I/O  flag  in  the  intertask 
communication  array.  If  that  flag  is  set,  then  the  task  must  wait  to  do  its 
I/O.  When  a  task  is  done  with  FORTRAN  I/O,  it  will  reset  the  flag.  Battelle 
also  added  a  command  to  CRT01  to  manually  reset  the  flag  in  case  a  task  aborts 
before  resetting  it. 


Main  Tape  Directory  Sorting  (4. 6. 2. 7) 


REQUIREMENTS 

Additional  sorting  of  Main  Tape  Directory  information  by  an  online  terminal 
user  is  needed  to  ease  directory  use. 


BATTELLE  ACTIONS  AND  RESULTS 

Battelle  completed  this  subtask  by  studying  the  requirements  for  additional 
sorting  of  the  Main  computer  tape  directory,  then,  discovering  and  correcting 
software  search  algorithims.  Additional  capabilities  were  added  to  the  tape 
directory  software  by  allowing  it  to  also  search/sort  on  tape  numbers  and 
dates. 
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Maintain,  Enhance,  and  Develop  Software  for  the  Main  Computer  Heeded  to 
Support  the  Pre-test  and  Post-test  Engineering  Simulation  and  Analysis  of 

Compressor-Related  Data  (4.6.3) 


REQUIREMENT 

The  contractor  shall  maintain,  enhance,  and  develop  software  for  the  Main 
computer  needed  to  support  the  pretest  and  post-test  engineering  simulation 
and  analysis  of  compressor- related  data.  Specific  tasks  include  the  conversion 
of  a  digitizing  program  to  run  on  the  Main  computer,  conversion  of  a 
structural  analysis  program  to  run  on  the  Main  computer,  development  of 
software  to  create  standard  format  test  article  data  tapes,  development  of 
software  to  merge  test  article  data  tapes,  and  development  of  software  to 
merge  facility  historical  data  tapes. 


BATTELLE  ACTIONS  AND  RESULTS 
Post-Processing 

The  post-processing  software  was  written  by  the  Air  Force  to  allow  a  user  to 
interact  with  the  run-time  software  and  process  old  data  from  Main  data  tapes. 
Post-processing  software  sends  the  data  through  the  reduction  software,  and 
displays  the  resulting  engineering  units  on  a  CRT  or  as  a  hardcopy. 
Post-processing  software  was  rewritten  to  use  the  new  task  communication 
routines,  and  to  be  able  to  process  the  data  from  tapes  that  are  now  stored  in 
a  different  format  than  previously.  8attelle  gave  the  software  the  necessary 
logic  to  distinguish  between  the  formats,  keeping  the  post-processing  software 
In  a  state  where  It  could  process  old  or  new  run-time  tapes. 

Battelle  added  the  capability  for  a  person  to  use  post-processing  software 
when  generating  a  standard  format  tape.  This  gave  users  the  ability  to  make 
standard  format  tapes  in  either  an  interactive  or  batch  mode.  The  batch  mode 
of  processing  is  much  faster,  but  the  interactive  mode  comes  in  handy  when  the 
user  does  not  know  before  hand  what  data  Is  to  be  put  on  tape. 

Battelle  created  a  new  version  of  the  post-processing  software  which  allows 
a  user  to  process  forward  and  backward  within  a  reading  number. 

Battelle  created  the  FDA  and  F100  libraries  to  make  Standard  Format  Tapes  from 
FDA  and  FI 00  compressor  test  data.  This  effort  Involved  modifying  and 
incorporating  the  reduction  software  at  the  end  of  each  test  with  the  current 
post-processing  software  being  used  in  the  Main  computer  production  libraries. 


Plotting  System 

Battelle  created  and  supported  the  tape  plotting  software  system  used  In  the 
CRF.  The  plotting  system  processes  Facility  Historical,  High  Speed,  and 
Standard  Format  Tape  (SFT)  data  to  produce  x-y  plots  of  user-selected 
variables.  Facility  Historical  Data  Tapes  contain  facility  information 
collected  by  the  Monitor  computer  during  actual  compressor  testing.  High 
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Speed  tapes  contain  20  variables  that  are  collected  on  the  FCC1  computer  at  a 
10  milliseconds  scan  rate.  Standard  Format  Tapes  contain  the  data  needed  to 
plot  compressor  maps  or  specific  test  article  performance  parameters.  All 
three  plotting  options  allow  the  user  to  read  a  data  tape  to  disk,  create  a 
plot  specification  file  where  the  user  inputs  what  variables  are  to  be  plotted 
on  each  plot,  generates  the  requested  plot  and  outputs  the  plot  vectors  to  a 
plotter  or  a  file  that  can  be  plotted  later  on  the  available  devices  in  the 
CRF. 

The  Standard  Format  Tape  plotting  system  also  Incorporates  a  scan  option.  It 
allows  the  user  to  scan  the  tapes  for  header  information,  and  up  to  five 
variables  before  printing  the  associated  values.  Another  option  allows  the 
user  to  read  selected  reading  numbers  from  a  group  of  Standard  Format  Tapes, 
and  output  the  "mixed  data"  to  a  disk  file  for  plotting,  thus  allowing  the 
user  to  make  plots  of  different  modes  of  data.  Battel le  created  standard 
batch  jobs  the  computer  operator  can  run  at  the  end  of  the  testing  day.  These 
jobs  read  all  the  static  data  type  information  from  the  run-time  data  tapes 
created  that  day  to  a  Standard  Format  disk  file  and  then  plot  the  Information. 
Battelle  wrote  the  first  High  Speed  plotting  program  to  run  on  the  FCC1 
computer  using  the  PL0T10  graphics  library  and  a  Tektronix  terminal.  Battelle 
moved  the  High  Speed  plotting  system  to  the  Main  computer  so  that  it  could  run 
faster  and  because  the  Main  computer  had  easier  user  access.  The  system  was 
converted  to  use  the  DISSPLA  language.  Battelle  then  designed  and  Implemented 
a  plotting  system  to  handle  Facility  Historical  and  Standard  Format  tapes. 
Battelle  took  the  three  tape  plotting  systems  and  merged  them  into  one  system 
called  TPLOT.  Battelle  gave  this  system  the  capability  to  print  data  as  well 
as  plot  it. 

When  the  conversion  to  the  IBM  MVS  operating  system  occurred,  TPLOT  was 
further  enhanced  to: 

-  Incorporate  procedures  to  process  classified  data. 

-  Modify  the  internal  reader  jobs  to  allow  the  user  to  create  a  plot  or 
"plot  file"  from  the  same  program. 

-  Modify  Standard  Format  tape  plotting  routines  to  allow  user  input  graph 
labels,  graph  legends  and  positions  and  plot  titles. 

-  Enhance  input  variable  screening  processes  to  allow  for  faster 
processing  of  transient  data  from  Standard  Format  tapes. 

-  Add  additional  DISSPLA  options. 


Digiplt  (4.6.3. 1) 


REQUIREMENTS 

Digiplt,  originally  written  to  run  on  the  CDC  computers,  allows  interactive 
digitizing  using  Tektronix  equipment.  It  has  been  converted  to  also  run  on 
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playback  requirements  to  develop  recommendations  for  merging  these  tapes  on 
the  Main  computer  and  maintaining  a  tape  directory  of  tape  Information. 
Consideration  shall  also  be  given  to  the  method  of  playing  back  tapes  after 
they  have  been  merged. 


BATTELLE  ACTIONS  AND  RESULTS 

Battelle  developed  the  first  version  of  software  to  merge  Facility  Historical 

data  tapes  on  the  IBM  MVT  system.  Systems  Research  Laboratory  is  now 

converting  the  software  to  the  IBM  MVS  system  and  making  enhancements.  * 


t 
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BATTELLE  ACTIONS  AND  RESULTS 

Battelle  designed  and  implemented  the  Standard  Format  Tape  Generation  (SFTGEN) 
software  on  the  IBM  computer  system.  This  software  incorporates  software 
engineering  techniques  in  conjunction  with  the  CRF  multi-tasking  routines  that 
allow  different  tasks  to  execute  simultaneously.  The  software  reads  Main 
Computer  run-time  data  tapes,  processes  them  through  the  online  software  in  a 
batch  or  interactive  mode  and  then  creates  a  Standard  Format  Tape  for 
analysis.  Standard  Format  Tapes  contain  documentation,  header,  units,  delete 
codes  and  engineering  values  data  for  each  file.  The  four  data  types 
(monitor,  static,  transient,  and  abort)  can  be  sent  to  the  tape,  but  each  tape 
will  have  only  one  type  of  data  stored  for  a  given  standard  format  tape 
generation  run.  The  software  can  select  start  and  stop  times  within  a 
millisecond  for  transient  and  monitor  data.  All  header  types  can  be  selected 
for  transfer.  The  software  provides  informative  written  output,  error 
messages,  and  internal  program  documentation. 

Many  enhancements  have  been  added  to  the  software  in  response  to  Air  Force 
priority  task  lists  to  keep  the  SFTGEN  software  current  with  CRF  needs. 


Merge  Main  Data  Tapes  (4. 6. 3. 4) 


REQUIREMENTS 

The  present  Main  online  software  requires  a  blank  data  tape  each  time  the 
software  is  started.  This  can  result  in  multiple  data  tapes  for  a  single  test. 
In  addition,  due  to  operational  errors,  invalid  entries  can  occur  in  the  Main 
Tape  Directory  maintained  on  disk.  The  contractor  shall  study  the  existing 
software,  tapes,  and  operational  procedures  to  develop  recommendations  for 
merging  these  data  tapes  and  for  modifying  the  Tape  Directory. 


BATTELLE  ACTIONS  AND  RESULTS 

Battelle  created  the  directory  maintenance  and  merge  Main  data  tape  software 
on  the  IBM  MVT  system  and  then  participated  in  its  conversion  to  the  IBM  MVS 
system.  Systems  Research  Laboratory  has  now  been  given  the  task  of  completing 
and  enhancing  this  software. 


Merge  Facility  Historical  Data  Tapes  (4. 6. 3. 5) 


REQUIREMENTS 

The  present  Monitor  online  software  records  facility  historical  data  on  tape 
for  post-test  analysis  and  playback.  The  recording  density  is  relatively  low 
which  results  in  relatively  high  tape  usage.  In  addition,  there  is  no 
automatic  directory  of  data  for  correlating  data  tapes  with  last  runs  or  run 
events.  The  contractor  shall  study  the  existing  software,  documentation,  and 
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Prime  computers.  The  contractor  shall  study  the  existing  versions  and  develop 
recommendations  for  providing  this  capability  on  the  Main  computer  using  the 
DISSPLA  graphics  software  package. 

BATTELLE  ACTIONS  AND  RESULTS 

The  Digiplt  software  was  obtained  from  the  Materials  laboratory  where  the 
software  was  running  on  a  Prime  computer.  At  the  CRF,  Battel le's  task  was  to 
convert  the  software  to  run  on  the  CRF  IBM  MVT  system.  The  software  was 
loaded  on  the  IBM,  software  modifications  were  made,  and  compile  and  link 
procedures  were  developed  and  executed.  Upon  execution  of  the  link  step,  it 
was  found  that  unidentified  external  routines  were  encountered.  Further 
research  found  that  the  unidentified  externals  were  extended  PL0T10  library 
routines  to  which  the  CRF  did  not  have  access. 

This  task  was  placed  on  hold  by  the  Air  Force.  It  was  anticipated  that  SAS 
software  implementation  would  replace  this  requirement. 


MESH3  (4. 6. 3. 2) 


REQUIREMENTS 

MESH3  and  its  related  analysis  programs  originally  written  to  run  on  CDC 
computers,  provide  structural  analysis  capabilities  which  are  not  available  on 
the  CRF  Main  computer.  The  contractor  shall  study  the  existing  software  and 
develop  recommendations  for  converting  this  software  to  run  on  the  Main 
computer. 

BATTELLE  ACTIONS  AND  RESULTS 

The  MESH3  software  was  reviewed,  documentation  generated  and  comments 
incorporated  into  code  as  required.  The  task  was  then  placed  on  hold  by  the 
Air  Force  due  to  the  amount  of  work  which  was  going  to  be  required  to  make  the 
custom  software  operational  on  the  IBM  computer. 

Further  study  indicated  that  the  CRF  shall  purchase  an  off-the-shelf, 
maintained  software  package  to  replace  the  MESH3  software.  SAS  software 
has  the  potential  to  meet  at  least  part  of  this  requirement. 


Generation  of  Standard  Format  Tape  Software  (4. 6. 3. 3) 

REQUIREMENTS 

Present  CRF  test  article  data  tapes  are  written  in  a  format  that  is  not 
generally  readable  by  other  computer  systems.  In  addition,  there  is  data  on 
the  tapes  that  is  not  of  general  interest.  However,  when  the  CRF  runs  a  test 
article  for  a  contractor,  data  tapes  of  the  test  results  are  required.  The 
contractor  shall  study  the  existing  software,  documentation,  and  data  tape 
format/content  requirements  in  order  to  provide  recommendations  on  developing 
this  capability. 
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Install  and  Utilize  two  CRT  terminals  to  provide  adequate  Interactive  Access 
to  the  CRF  Main  Computer  (4.6.4) 

REQUIREMENTS 

The  contractor  shall  install  and  utilize  two  CRT  terminals  to  provide  adequate 
interactive  access  to  the  CRF  Main  computer.  These  terminals  shall  be  IBM  3277 
compatible  so  that  they  will  interface  to  the  IBM  3272  terminal  controller  on 
the  CRF  Main  computer.  The  contractor  shall  provide  for  the  CRT  terminal 
maintenance  for  a  six  month  period. 


BATTELLE  ACTIONS  AND  RESULTS 

In  June  1984,  two  IBM  3277  terminals  and  keyboards  were  purchased  to 
facilitate  interactive  access  to  the  IBM  computer. 


Install,  Enhance  and  Maintain  the  IBM  MVS  Operating  System  (4.6.5) 
REQUIREMENTS 

The  contractor  shall  install,  enhance,  and  maintain  the  IBM  VM  and/or  MVS 
operating  systems.  While  these  operating  systems  are  not  now  in  use  at  the 
CRF,  conversion  from  MVT  is  likely  within  the  next  24  months. 


BATTELLE  ACTIONS  AND  RESULTS 

In  April  1986,  the  IBM  computer  operating  system  was  upgraded  to  the  Multiple 
Virtual  Operating  System  (MVS)  by  System  and  Applied  Sciences  Corporation 
(SASC).  Battel le's  task  was  to  make  the  application  software  running  with 
MVS.  This  proved  to  be  a  much  larger  job  than  the  Air  Force  had  anticipated. 
The  majority  of  the  application  software  would  not  compile  with  the  new 
version  of  FORTRAN  that  came  with  MVS. 

Each  of  the  four  hundred  run-time  software  routines  was  reviewed  which 
incorporated  approximately  70,000  lines  of  code.  Each  routine  was  modified  to 
compile  and  link  with  the  new  version  of  FORTRAN.  Tasks  were  linked  together 
and  testing  was  performed.  The  assembler  routines  which  read  the  Modcomp  1950 
links  posed  the  biggest  problem.  The  MVS  operating  system  wasn't  as  tolerant 
of  existing  idiosyncrasies  as  the  MVT  operating  system.  Changes  were  made  to 
the  channel  programs  which  read  from  and  wrote  to  the  1950  link.  Pratt  and 
Whitney  programmers  who  originally  developed  the  channel  programs  that  talked 
to  the  1950  link  were  called.  They  informed  us  that  the  1950  link  created 
interrupts  on  the  link  at  a  much  faster  rate  than  the  new  operating  system 
thought  was  normal,  so  the  operating  system  locked  up.  A  'zap'  to  the 
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operating  system's  threshold  level  for  this  type  of  interrupt  was  installed  by 
SASC  which  allowed  the  IBM  and  the  Modcomps  to  talk  to  each  other.  The 
post-processing  software  was  then  converted.  (There  remains  to  be  a  number  of 
application  programs  in  the  CRF  which  have  not  been  converted  to  run  on  the 
MVS  system  as  of  August  1,  1988.) 


< 


* 
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GLOSSARY 


ADPE  Automated  data  processing  equipment 

AFB  Air  Force  Base 

AFSC  Air  Force  Systems  Command 

AFWAL  Air  Force  Wright  Aeronautical  Laboratories 

ATP  Acceptance  Test  Procedure 

AUX  Auxiliary  computer 

BPI  Bytes  per  inch 

CRF  Compressor  Research  Facility 

CRFNET  CRF  Computer  Communications  Network 

CRT  Cathode  Ray  Tube 

CSP  Command  String  Processor 

DAC  Data  Acquisition  Computer 

FCC  Facility  Control  Computer 

FCC1  Facility  Control  Computer  1 

FCC2  Facility  Control  Computer  2 

FHD  Facility  Historical  Data 

GCOM  Global  Common  Database 

GKS  Graphics  Kernal  System 

hp  Horsepower 

HPDAS  High  Performance  Data  Acquisition  System 

IBM  International  Business  Machines 

IGP  Interactive  Graphics  Processor 

IGV  Inlet  Guide  Vane 

IOIS  Input/Output  Interface  System 

ISPF  Interactive  System  Productivity  Facility 

LDV  Laser  Doppler  Velocimeter 

LTA  Laser  Transit  Anemometer 

Main  Main  Computer 

Masscomp  Masscomp  Computer 

Max  Modcomp  Operating  System 

Max  III  Modcomp  II  Operating  Systems 

Max  IV  Modcomp  Classic  Operating  System 

Modcomp  Modular  Computer  Systems 

Monitor  Monitor  Computer 

MVS  IBM's  Multiple  Virtual  Operating  System 

PCAL  Pressure  CALibration 

PLC  Programmable  Logic  Controller 

PLC1  Programmable  Logic  Controller  #1 

PLC2  Programmable  Logic  Controller  #2 

POTX  Propulsion  Technology 

Preston  Analog  to  digital  signal  converter 

Ramtek  Color  graphics  generator 

rpm  Revolutions  per  minute 

RTU  Masscomp  real  time  unix  operating  system 

SASC  Systems  and  Applied  Sciences  Corporation 

SRL  Systems  Research  Laboratories 

S2K  System  2000  database 

TAC  Test  Article  Control  Computer 

TAC1  Test  Article  Control  Computer  1 

TAC2  Test  Article  Control  Computer  2 
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TRV  Traverse  table 

TSO  Time  Sharing  Option 

UPS  Un Interrupt able  Power  System 

WPAFB  Wright  Patterson  Air  Force  Base 

WRAIS  Wide  Range  Analog  Input  System 
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